dev/etc

[OAuth 2.0] Store token and re-authentication

재삐신생 2017. 2. 15. 10:41
반응형

목적

OAuth 2.0을 사용하여 얻은 토큰의 관리 방법에 대한 내용으로,
사용자의 재인증을 피하며, 토큰의 무분별한 발급을 줄여보자는 취지이다.

수많은 외부 서비스 API에서 채용하고 있는 OAuth 2.0

사용법은 그리 어렵지 않다.

  1. 사용자에게 해당 외부 서비스에서 로그인을 요청
  2. 사용자의 로그인 및 정보제공 동의
  3. 리다이렉트로 authentication code를 받고
  4. 이것으로 access token을 발급받는다.
  5. access token을 이용해서, API를 사용

허나, access token은 고유값이 아니다. 만료시간이 있으며, 만료가 되기전에 갱신을 받을 수 있다.

물론, 서버에서는 갱신 프로세스를 자동화시키면, 계속해서 활성화된 access token을 유지할 수 있지만, 보안 문제점을 야기할 것이다.


소셜로그인

API를 통해 사용자의 정보를 받아, 해당 사용자 정보를 받아서, 사용자를 식별 하게 된다.

이과정이 소셜로그인이다.

그리고 추가로 회원정보를 받는 경우, 그렇지 않은 경우가 있으며, "???으로 가입하기" "???으로 계속하기" 전부 같은 말이다.


추가회원정보를 받거나, 로그인정보(ID,PW)를 받아서, 일반로그인을 지원하는 경우(정보가 일치하여, 기존회원과 병합하거나)

혹은, 바로 서비스를 이용할 수 있더라도, 실제로 받은 사용자정보는 저장을 하게 된다.

(시나리오에 따라, 소셜로그인 후가 아닌, 다른 시점(해당 개인정보가 필요한 시점)에 요구하는 경우도 있다.)

이부분은 소셜로그인시 개인정보 제공에 관련된 내용에 포함되어 있다.


필자는 위의 일반적인 경우말고, 사용자 정보를 전혀 저장하지 않고, 현재 접속한 사용자에 대해서만 처리(세션 이용)를 하고 싶었지만,

결국, 실패하였다.

이유은 비회원과 다를게 없기 때문이다. 시스템상에서 식별할 어떠한 정보도 없기 때문이다.


토큰 저장

OAuth인증을 수행하면서, 받은 토큰은 어떻게 할것인가??

소셜로그인 API의 경우, 현재 세션은 로그인이 된 상태이므로, access token은 사용할 일이 별로 없다.


하지만, 다른 API의 경우는 다르다.

소셜로그인이 로그인시 사용자정보를 가져오는 용도로만 token이 활용되었지만,

지속적으로 필요한 경우도 있다. 심지어 사용자가 로그인하지 않은 상황에서도 token이 필요한 경우도 있다.


그렇다면 token을 저장하여야 할 것이다.

저장된 access token이 만료되지 않도록 유지해야할 필요가 있으면, refresh token을 사용, token을 갱신하여야 한다.

refresh token이 만료되었다면, 재인증이 필요한다.

토큰 갱신이 필요한 상황은 별로 없는 듯 하다.


토큰 갱신이 필요한 상황

  1. 매우 긴 시간동안 세션유지가 필요한 경우(eg. 모니터링) 혹은, 토큰 만료시간이 매우 짧은 경우
  2. 사용자 요청없이, 외부 API를 사용하여야 할 경우(eg. 자동화)
  3. 기타??


서버에 token을 저장하는게 맞는가??

token에는 scope가 정해져 있지만, 필요하지 않은 범주의 것에도 접근이 가능한 token을 계속 저장한고 있는 것이 과연 옮은일지 모르겠다. 그럴리는 없겠지만, 서버가 해킹당해 client id, secret과 token이 유출된다면, 어떻게 될까??

외부 서비스에 따라 다르겠지만, 대부분, 블로그나 SNS를 포함하고 있으며, 글을 쓰거나, 사진을 변경하는 것이 가능하다. 이것은 충분히 또다른 문제를 야기할 수 있다.

이 문제는 클라이언트를 활용하는 방법이 있다.(이미 javascript sdk는 그렇게 하고있다.)

어차피 token은 해당사용자에게 소유권(?)이 있으니 client에 저장(cookie or local/session storage)을 하여도 된다.

이또한, 마음에 걸린다면, encrypted된 token을 서버에두고, client에는 decrypt key를 저장하는 방법도 있을 것이다.

이것은 어디까지나, 사용자가 로그인된 상황에서만 가능하므로, 자동화는 불가능하다.


재인증

재인증이란 access token이 만료되어, 재인증이 필요한 상황에 발생한다.

혹은, 이외에도 재인증이 필요한 경우는 보안 정책에 따라 존재한다.

이외에, 이미 활성화된 토큰이 있는데도, 또 재인증을 하여야 한다면, 불필요한 재인증일 것이다.


결론

발급받은 토큰을 오래사용해보자

소셜로그인 사용시에 재로그인을 하면, 이는 재인증이며, token을 새로받게 된다.

OAuth인증시 authentication code를 받기까지는 당연한 과정이지만, 이 후 token을 다시 받을 필요는 없는 것 같다.

이미 사용가능한 토큰이 존재한다면, 재사용을 해도 될 것 같다. (이게 맞는지는 정확히 모르겠다)

하지만 token을 client에 저장한게 아니라면, 현재 로그인한 사용자에게 발급된 token을 확인할 수가 없다.

그래서, client에 토큰을 저장 및 사용자의 고유값을 가지고 있다면, 기존 token을 사용할 수 있을 것이다.

즉, 재인증은 하되, token은 이전것을 쓴다.

로그인시 사용한 token과 사용자의 고유값을 서버/클라이언트에 동시에 저장하여, 로그인시, authentication code만 받고, 다시 token을 새로 발급받지 않고, 이전에 발급받은 token을 사용하는 방법(validate나 refresh가 필요하면 수행)


해보십시다.


refer:

https://oauth.net/2/

http://tutorials.jenkov.com/oauth2/authorization.html

http://security.stackexchange.com/questions/72475/should-we-store-accesstoken-in-our-database-for-oauth2


반응형

'dev > etc' 카테고리의 다른 글

2017년에 꼭 배워야할 언어 프레임웤 툴  (0) 2017.03.02
stateless and stateful  (0) 2017.03.02
git .gitignore 적용 (apply gitignore)  (0) 2016.12.08
ubuntu on docker on windows  (0) 2016.05.17
SSD를 위한 Windows 최적화  (0) 2016.05.13