토큰 DB 저장 관련 논의사항

[Jin409]

@seongminn @jeongnaehyeok @jiwon918 @younghch

안녕하세요! 토큰 관련해서 몇 가지 논의사항이 있어 제가 정리한 내용을 공유하고, 의견을 여쭙고자 합니다!
제가 토큰에 관해서 정리하면서 여러 가지 고민되는 지점들이 생겼었는데요,

1. DB 에 저장할 것인가 말 것인가 
2. 한다면 Redis 가 적절하다고 생각하는데 맞을까 
3. 탈취에는 어떻게 대응할 것인가 
4. refresh / access 토큰의 유효기간은 어느 정도가 적당한가 였습니다. 

관련해서 의견 자유롭게 남겨주시면 좋을 것 같습니다!

추가적으로, 해당 부분에 대한 논의가 이루어지고 나서야 클라이언트 측과의 플로우도 정립될 것 같아 이 부분부터 정하고 나아가면 어떨까 하여 해당 부분은 우선 제외시켰습니다!

토큰 vs 세션

1. 세션 기반

• 사용자의 인증 정보를 서버 자체 내부의 메모리인 세션에 저장
• Session ID 를 사용자에게 발급
• 메모리 낭비 우려
• 클라이언트가 cookie header 에 session id 를 저장해서 전송 및 사용
• MSA 에 적합하지 않다. ⇒ 세션 정보가 각각 다르기 때문에 불일치 문제가 생길 수 있다.

2. 토큰

• 인증 정보가 클라이언트에게 존재
• http 요청 시 Authorization Header 에 담아서 요청을 보냄
• 별도의 메모리가 존재하지 않는다

Reference Token vs Self Encoded Token

1. Reference Token

• 정보를 포함하지 않는 토큰
• 토큰 삭제, 유저 정보 변경 등이 가능하다.
• 저장소에 저장을 해야 한다.

2. Self Encoded Token

• 토큰 자체에 정보를 포함하기 때문에 유효성 검증을 위해 DB 에 접근할 필요가 없다.
• 저장된 정보는 발급 시에만 유효하기 때문에 정합성이 맞지 않을 수 있다.

토큰 DB 에 저장하기 vs 하지 않기

1. 토큰을 DB 에 저장하지 않는 이유

• 클레임 기반 토큰은 이미 토큰 내부에 정보가 있기 때문에 유효성 검증이 토큰 자체로도 가능함
• 기기 간의 호환성 문제
  • 보안상의 이유로 로그인을 할 때마다 새로운 리프레시 토큰을 발급한다면, 기기 간의 리프레시 토큰의 불일치가 발생하여 기기 이동이 있을 때마다 로그인을 하도록 해야 하기 때문에 UX 적으로 좋지 않다.
• stateless 한 JWT 의 의미에 대한 의문
  • JWT 는 stateless → 즉 서버에 상태를 저장해서는 안된다. 그런데 DB 에 저장하는 것은 모순이 아닐까?

참고

2. 클레임 기반이라고 하더라도 토큰을 DB 에 저장하는 이유

• 사용자를 강제로 로그아웃 및 차단시킬 수 있음 → 리프레시 토큰을 DB 에서 삭제할 수 있기 때문에
• 보안상의 이유
  • 만약, 리프레시 토큰이 만료되기 전에도 재발급을 한다면 보안상의 이유로 재발급을 하는 경우 가장 최근에 발급된 리프레시 토큰과 일치하는지 확인해야 하기 때문에

탈취 대응 시나리오

1. 액세스 토큰을 갈취하는 경우

• 액세스 토큰의 유효기간을 적당히 짧게 설정하여 오랜 기간동안 탈취할 수 없도록 한다.

2. 리프레시 토큰까지 갈취하는 경우

• RTR 로 대응 가능
  
  • RT 를 사용해서 새로운 AT 를 발급받을 때마다 항상 RT 도 새로 발급하는 방법

적절한 데이터베이스

redis 를 사용하는 이유

1. 캐시와 같이 자동 삭제일을 지정할 수 있다. (토큰의 만료일을 지정할 수 있음)
   • rdbms 의 경우, 오래된 리프레시 토큰도 계속해서 저장하고 있기에
2. key-value 형태이기 때문에 속도가 빠르다.

결과

1. 세션 vs 토큰

• 세션 정합성 문제 + MSA → 토큰이 알맞다고 생각.

2. Reference vs Self Encoded

• Reference 의 경우에는 서버가 여러 개이면, 토큰 내부에 정보가 없어서 어떤 권한을 갖고 있는지 확인하기 어려울 수 있다.
• MSA 에 적합한 self encoded 방식이 적합하다고 생각.

7. DB 저장 or not

• 논의가 필요할 것 같습니다.

8. 탈취 대응 시나리오

• DB 저장 여부와 같은 맥락에서의 논의가 필요할 것 같습니다.

9. 액세스 토큰 / 리프레시 토큰의 적절한 유효 기간

참고 자료

https://junior-datalist.tistory.com/352
https://hudi.blog/refresh-token/
https://sol-devlog.tistory.com/22
https://meetup.nhncloud.com/posts/239

[younghch]

깔끔한 정리 너무 감사합니다.

1. 세션 vs 토큰

• 토큰이 알맞다는데동의합니다.

2. Reference vs Self Encoded

• self encoded 사용에 동의합니다.
• reference token 사용은 세션 사용과 차이가 없다고 생각합니다.

3. DB 저장 or not + 탈취 대응 시나리오

   사용자를 강제로 차단해야 하는 케이스

   이를 구현하려면 DB저장이 필수적이라는데는 동의합니다. 필요성에 대해서는 저희 서비스가 토큰을 회수하는 시점을 적절히 구성하지 못해도 민감한 정보가 없고, 꼭 재확인이 필요한 기능에서 유저정보 유효성을 db에서 직접 확인하는걸로 대체 가능하다고 생각합니다.

   보안상의 이유

   토큰이 탈취될 수 있는 상황을 정립해 보는게 도움이 될것 같아 정리해봅니다.

   1. 유저가 외부 OAuth서버에 동의후 토큰을 받아오는 중 redirection url이 조작되는 경우 (CSRF)
      PKCE로 토큰을 직접 생성하는 대신 access_code를 유저에게 전달하고 code verifier를 access_code와 같이 검증해 탈취 방지
   2. 우리 서비스에서 자체 발급한 토큰이 탈취되는 경우
      • 클라이언트와는 tls 통신을 하기 때문에 네트워크 상에서 탈취가 일어나지 않을겁니다.
      • 브라우저 로컬 스토리지 상에 저장된 토큰이 탈취되는 경우가 가장 가능성이 크네요.
      • 혹시 다른 경우가 있다면 알려주세요!

   악성 코드가 유저가 토큰을 받을때마다 실행되는게 아니라, 우연히 한번 실행된다는 가정하에 말씀주신 것처럼 access 토큰이 탈취되는것은 짧은 유효기간이 끝나면서 해결될 수 있습니다. refresh token이 탈취된 경우에는 계속 access토큰과 refresh토큰을 발급되는 문제가 생깁니다. 이 경우 해결법으로 제시해주신 RTR을 사용하는게 좋다고 생각합니다. 이 경우에는 저희가 refresh token정보를 db에 저장해 놓는게 필수겠네요. refresh token 저장은 redis가 필요하지 않다고 생각합니다.
   다른 해결법으로는 silent_authentication으로 refresh token을 아예 발급하지 않을 수도 있습니다. 이부분은 구글에서는 되는것 같은데, 카카오에서도 되나 확인 해봐야 할것 같아요.

4. 액세스 토큰 / 리프레시 토큰의 적절한 유효 기간
   OAuth 2.0 명세에서 lifetime을 검색해봤는데, access code에 대해서는 10분의 유효기간을 권장하지만 토큰에 대해서는 명시된게 없네요. access token에 대해서는 유저가 저희 서비스에 한번 접속했을 보통 얼마나 머무는지 기준으로 가면 좋을 것 같습니다. refresh token은 유저가 해킹당해서 저희에게 문의를 했을 때 db에 저장된 refresh token을 수동으로 삭제하고 '몇일 뒤에 괜찮아 질겁니다' 했을 때 유저가 납득할 수 있으면서 매번 로그인을 해야되는 귀찮음을 덜 수 있는 시간을 찾아야 할 것 같습니다.

[Jin409]

안녕하세요 용훈님! 답변 감사드립니다.
질문이 몇 가지 있어 남겨봅니다 :)

1. 왜 redis 가 필요하지 않다고 생각하시는지 여쭤봐도 괜찮을까요? 저의 경우에는 redis 가 유효기간이 지난 경우 자동적으로 삭제를 해주어 메모리를 절약할 수 있기 때문에 토큰을 사용한다면 가장 좋은 방법이 아닐까 싶었습니다! (물론 db 에 저장한다는 결론이 내려진 이후라면요!!)
2. access 는 10분, refresh 유효기간에 대한 의견 너무 좋습니다!

[younghch]

말씀주신대로 refresh 토큰 저장소로 redis를 사용하면 토큰확인이 더 빠르다는 장점이 있을 것 같습니다. 다만 redis 사용은 다수의 유저가 자주 조회하는 데이터애 대해 사용하는게 더 적합한 것 같습니다.

redis는 데이터를 메모리에 저장합니다. refresh 토큰의 유효기간은 몇일 이상으로 길고, RTR을 사용하기에 한번만 조회됩니다. 가끔 일어나는 한번의 조회를 위해 미리 메모리를 할당할 필요는 없다고 봅니다.

RDB에 넣어놓고 refresh token 요청이 왔을 때 사용여부를 확인하면 될 것 같습니다. 사용 후 바로 삭제해도 좋고 사용 여부를 필드로 놓아도 좋습니다. 유효기간은 토큰 자체에 포함되어 있을테니 저장할 필요는 없을 것 같습니다. 다만 유효하지 않은 토큰을 삭제해야한다면 필요하겠네요.

[jeongnaehyeok]

1. 세션 vs 토큰
   토큰 기반이 좋습니다.

2. Reference vs Self Encoded
   잘몰라서 찾아봤는데, 토큰을 사용한다고 생각했을떄, Self Encoded가 좋을 것 같습니다.

3. 토큰 DB 에 저장하기 vs 하지 않기
   큰 의견이 없긴 하지만, 외부 서비스 인증 사용시, DB에 저장해야한다고 생각합니다.

4. 탈취 대응 시나리오
   저장된 인증값을 비교하고 막아야할 것 같습니다. 해당 건도 큰 의견없긴합니다.

5. refresh / access 토큰의 유효기간은 어느 정도가 적당한가 였습니다.
   GA를 보면서 기준으로 점점 맞춰가면 좋겠지만, 저희 서비스가 그렇게 고도화 되자 않을 것 같아서 일주일이면 적당할 것 같습니다