[개발 이슈] 서비스가 이벤트를 발생시키는 주체가 어떤 사용자인지 어떻게 구분하지? / access token, session, refresh token

서비스의 기능들을 만들어가다 문득 이런 생각이 들었습니다. '서버는 클라이언트의 요청에서 어떻게 사용자를 구분할까?' 사실 서버가 클라이언트 요청으로 사용자를 구분하지 못하면 제대로 작동할 기능이 얼마 없을 것입니다. 이를 해결하는 방법은 다양하지만 본 프로젝트에서는 소셜 로그인을 활용하는 만큼, kakao에서 로그인 성공시 응답해주는 access token을 활용하기로 결정 했습니다.

 

 

 

access token

In computer system, an access token contains the security credentials for a login session and identifies the user, the user's groups, the user's privileges, and, in some cases, a particular application. (위키 백과)

위 글을 요약 하자면 access token은 로그인 과정에서 발급해주는 증명서라고 볼 수 있습니다. 우리가 놀이공원에서 처음 입장할 때 구매한 자유이용권으로 놀이공원 내 시설을 이용하듯이 로그인을 통해 발급받은 access token은 로그인을 한 서비스 내의 다양한 기능들을 이용하게 도와줍니다. 간단히 예를 들어서 클라이언트가 자신의 정보를 수정하기 위해서 값을 입력하고 서버에 요청을 했을 때, 사용자가 수정하려는 정보의 주인이 맞는지 확인해야 될 것입니다. 이 때, 서버는 access token을 통해서 사용자를 검증하게 됩니다.

 

HTTP session

그렇다면 서버는 정확히 어떤 방법으로 access token을 통해 사용자를 검증할까? 다양한 방법이 있지만 제가 사용한 방법은 session에 access token 값을 보관하는 방법입니다. spring에서 제공하는 HttpSession 객체를 불러와 로그인 시 발급 받은 access token 값을 보관하고 사용자 검증이 필요할 때마다 session에 접근하여 값을 불러왔습니다. 

아래 이미지는 본 서비스에서 로그인을 했을 때 session에 저장되는 accesstoken값입니다.

위 정보를 자세히 보면 놀이공원의 자유이용권도 정해진 기간에만 이용이 가능한 것처럼 토큰 또한 발급 이후 검증되는 정해진 시간이 존재합니다. 이를 갱신하고 유지 관리를 맡는 것이 refresh token이고, 아직 본 프로젝트에는 refresh token을 적용시키지 않았기 때문에 access token의 time-out 이 지나면 해당 사용자는 인증(로그인)을 다시 받아야 합니다.