프로젝트 진행 중에 Accesstoken과 관련한 문제가 생겼다.
회원 쪽에서 AWS Cognito를 사용하는데, 로그아웃 시에 cognito의 revokeToken(), globalSignOut() 메서드를 이용하면 refreshToken은 잘 만료 시켜주지만, 그 전에 발급된 accessToken은 내가 설정한 만료기간동안 만료되지 않고 그 시간동안 사용할 수 있다.
위의 두 메서드를 사용하면, accessToken은 cognito 상에서 취소된 토큰으로 설정되긴 한다. 다만 취소됐다는건 cognito 메서드를 통해 accessToken을 보낼 때만 revokedToken으로 사용할 수 없다고 할 뿐, 현재 서비스에서는 accessToken이 revoked되었는지 확인할 방법이 없기 때문에 설정한 만료시간동안은 사용할 수 있는 것이다.
cognito에 메서드를 요청할 때, accessToken을 담아보내는 경우가 거의 없기 때문에 accessToken을 어떻게든 사용못하게 할 방법을 찾았다.
처음에는 redis를 생각했다. 블랙리스트로 관리하여 accessToken 을 관리할 방법을 생각했지만, 선임님이 이건 지금 서비스에서 붙이기엔 적절하지 않다고 했다.
차라리 지금 상황에서는 accessToken을 로그아웃 하는 시간과 accessToken을 DB에 기록하여 로그아웃 한 시점으로 springSecurity를 이용해서 요청시에 DB에 기록된 accessToken에 대한 요청을 아예 막는 방법.
그래서 할 방법을 찾다가, 갑자기 accessToken에 대해 찾아봤고 이 블로그를 발견함.
- https://hudi.blog/refresh-token/

음.. 여기서 stateless에 대해 내가 잘 이해하지 못했다고 생각. stateless에 대해 찾아보기 시작했다. 😕
그리고, JWT(Json Web Token)은 claim 기반의 토큰인데, 여기서 claim은 사용자에 대한 프로퍼티나 속성을 얘기한다. 토큰 자체가 정보를 가지고 있는 방식인데, JWT는 이 Claim을 JSON을 이용해서 정의한다.
아까 얘기했던, revoke됐지만 만료되지 않은 accessToken을 들고 요청할 경우 springSecurity에 걸려서 요청이 취소되는 건. session방식인가?

위의 글들을 다 종합해보면, 결국 내가 하려했던건 stateless하지 않고, stateful 한 방식이고 JWT를 사용하는게 의미없는 방법인 것 같다. 차라리 이럴거면 세션을 사용하지? 라는 식의 말... ? 맞는지 다시 찾아보자.
근데, 여기서 얘기해본건
로그아웃 때는 accessToken을 담아서 뭐 세션방식이던 JWT방식이던 아무튼 못하게 처리했다고 친다. 근데 서비스에서 중복로그인을 불가능하게 해야하는데, A 디바이스로 먼저 로그인을 한 후, B디바이스로 로그인하면 A로그인이 풀려야되는데 여기서 accessToken이 만료가 안되므로 DB에 저장하는 방법으로도 A로그인을 풀리게 할 방법이 없다. 이러면 로그인할때도 accessToken을 저장해야하는데 이건 좀 아닌거같다. 고도화 때 다시 방법을 찾아보도록 하자...