[리팩토링] Access Token, Refresh Token 인증 프로세스
Intro
리팩토링 중인 프로젝트의 토큰 인증 프로세스를 구상해 보았다.
토큰 형식
Access Token 형식 : JWT
Refresh Token 형식 : UUID
Refresh Token 저장 형태
| Key (String) | refreshToken:{사용자 아이디} |
| Value (String) | real_refresh_token |
토큰 인증 프로세스 순서도
결론
구글링과 github의 다른 개발자들의 프로세스를 찾아보아도 인증 프로세스가 일관되지 않아서 굉장히 고민을 많이 했다. 특히 Access Token 재발급 시에 Refresh Token 갱신 유무를 고민했는데 마침 Refresh Token 탈취 위험에 대한 OAuth의 Refresh Token Rotation에 대한 글을 읽었다. Refresh Token Rotation은 클라이언트가 Access Token를 재요청할 때마다 Refresh Token도 새로 발급받는 것이다. 이렇게 되면 탈취자가 가지고 있는 Refresh Token은 더 이상 만료 기간이 긴 토큰이 아니게 된다. 따라서 불법적인 사용의 위험이 줄어든다. 해당 글에 따라 Access 토큰 재발급 시에도 refresh 토큰을 갱신하는 것으로 프로세스를 구상하였다.
그리고 토큰의 키로 사용자 아이디를 사용하였는데 이 부분이 좀 마음에 걸린다. 고유 아이디를 키로 사용함에 불법적인 사용자가 키를 탈취할 경우 해당 아이디까지 탈취당하는 것이 아닌가 하는 생각이 들었다. 아이디보다는 이메일이나 다른 unique 한 속성을 사용하고 싶은데 해당 프로젝트의 회원 테이블이 굉장히 간단하게 되어있어서 unique 한 속성이 유저 아이디와 테이블의 PK로 사용 중인 고유 아이디밖에 없다. 아무래도 이 부분도 개선해서 이메일을 키로 사용할 수 있도록 하는 것이 좋을 듯싶다.
참고