- JWT를 이용하는 방식 (ft. refreshToken, accessToken)
(1) 유저가 로그인할 때 (2) 서버가 인증 정보를 보내주는데, 암호화나 시그니처 추가가 가능한 데이터 패키지안에 인증 정보를 담아 보내준다. (이 패키지가 JSON Web Token 즉 JWT다.) (3) 담기는 정보 중 accessToken과 refreshToken이 이후 유저 인증에 사용되는데 (4) 이 정보를 클라이언트에 저장해둔다.
좀 더 자세히 설명하면 실질적인 인증 정보는 accessToken인데 일정 시간이 지나면 만료하는 구조를 가지고있다. (로그인 후 며칠 뒤 로그인이 만료돼서 다시 로그인해야 했던 경험이 있는가?) refreshToken을 이용해 로그인을 지속적으로 유지할 수도 있다. refreshToken을 서버에 보내면 그때마다 새로운 accessToken을 발급해 돌려주는 거다. refreshToken 사용은 옵션이다.
그럼 다시 돌아와 (5) 이 accessToken을 유저에게만 보여줄 수 있는 정보에 접근할 때 서버에 보내면 (6) 서버는 그 토큰이 유효한지 확인하는 방식으로 인증한다.
종합해보면 세션 id를 브라우저에 저장하는 방식은 어떤 방식이던지 보안 위험요소가 있으므로 JWT 이용한 인증 방식을 사용할 것이다. refreshToken만을 secure httpOnly 쿠키에 저장할 것이다. accessToken은 웹 어플리케이션 내 로컬 변수에 저장해 사용하며, API를 요청할 때 Authorization 헤더에 넣어 보내준다.
로그인 만료, 로그인 연장하기
JWT 인증 방식에서 실질적으로 인증되었나를 결정하는 것은 accessToken이다. 하지만 우리가 택한 구조에서 브라우저에 저장된 값은 쿠키에 저장된 refreshToken뿐이기에 로컬에 저장된 accessToken은 브라우저 창이 꺼지거나 페이지가 리프레시 되는 등 페이지가 리로드 되면 사라진다. 또한, accessToken은 일정 시간이 지나면 만료된다. 그래서 (1) 이메일, 비밀번호를 입력해서 accessToken을 받아오는 보통 로그인 처리뿐만 아니라 보다 완성도 있는 사이트를 만들기 위해 (2) accessToken이 만료됐을 때 어떻게 처리할지 (예를 들어 은행 사이트같이 보안이 중요한 서비스라면 아예 다시 로그인하도록 로그인 페이지로 이동시킬 수도 있고, 아니면 유저 모르게 서버에서 새로운 accessToken을 받아와서 로그인이 연장되도록 할 수도 있음), (3) 페이지 리로드 될 때 어떻게 처리할지 (2번과 같이 여러 가지 처리 방식이 있음)도 결정해야 한다.
다음 글에서는 서버와 통신하여 accessToken이 만료 되었을때의 API와 전역변수를 통한 상태 관리를 하여 로그인 상태에 따른 창 분리를 해볼 예정이다.
