RESTful 아키텍쳐와 토큰 / JWT vs Session

REST API에서는 서버가 session을 가지지 않는다.

물론 REST API서버에도 session을 추가하여 사용할 수 있지만, 이는 REST가 지향하는 바가 아니다.

대신 REST API는 토큰(token) 인증방식을 사용하게 된다.

로그인 API로 아이디와 패스워드가 일치함이 확인되면 서버는 토큰을 발행하고, 로그인 후 이용가능한 API들에는 유효한 토큰이 있는 경우에만 사용할 수 있게 된다.

이때 토큰은 당연하게도 위조하기가 어려워야 하며 사용자를 인식할 수 있는 정보가 들어있어야 합니다.

토큰의 예로는 JWT 토큰(JSON Web Token)이 있다.

유저가 회원정보를 JSON 형태로 서버에게 전송한다

{'id' : 'Hevton', 'email' : 'hevton.io'}

서버는 이 데이터를 BASE 64 인코딩하여 직렬화하고, 개인키를 통한 전자서명 작업을 하여 서명을 붙여준다.

그리고 이렇게 만들어진 값을 유저에게 보내준다.

유저는 앞으로 통신할 때 이 값을 이용하며, 서버는 유저가 보낸 값을 공개키를 통해 서명인증을 하고

서명을 확인하여 유효한다면, 인코딩된 유저의 정보를 디코딩하여 이용한다.

JWT 토큰의 내부 구조를 조금 더 자세히 들여다보면, 크게 세 가지로 볼 수 있다.

위 1, 2, 3을 또 Base64 인코딩 하여 보낸다.

JWT의 장점은

세션값처럼 서버 내 DB에 저장할 필요가 없다.

쿠키를 브라우저 같은 곳에 저장하지 않는 모바일 앱의 특성상, 모바일 쪽은 주로 JWT 토큰을 사용하기도 한다.

JWT는 세션처럼 모든 사용자들의 상태를 기억하고 있지 않다.

예를 들어, 한 기기에서만 로그인이 가능한 서비스를 만들고 싶다면, 세션을 이용한다면 pc에서 로그인하면 핸드폰에서의 세션값은 사용못하게 하는 등 제어할 수 있다.

반면 JWT는 이미 줘버린 토큰을 뺏을 수가 없다. 해커에게 토큰을 빼앗겨도 토큰을 무효화할 방법도 없다.

이를 '보완' 할 방법이 있긴 하다.

accessToken: 매번 인가를 받을 때 사용하는 토큰. (보통 수명이 짧음)
refreshToken: accessToken의 수명이 다했을 때 accessToken을 재발행 받기 위한 토큰이다. 보통 2주정도 기간을 길게 잡는다.
(누군가를 로그아웃시키려면 refeshToken을 db에서 지워버리면 되는데 그래도 accessToken의 수명 동안은 바로 차단할 방법은 없다.)

이러한 JWT 토큰의 유효기간 관리에 대한 문제로 보안의 위협이 단점이다.

또한 상대적으로 길이가 길다.

참고

관련글