인증과 토큰

일반적으로는 사용자가 로그인에 성공하면 서버는 클라이언트에 토큰을 제공해준다. 이후 클라이언트는 요청을 할 때 마다 토큰을 함께 전송하고, 서버는 이 토큰을 검증한 뒤 요청을 처리해준다.

토큰을 통해 사용자를 식별하기 위해 크게 아래 2가지 방법을 사용한다.

1. 서버의 별도 저장소에 토큰과 사용자 식별정보 저장
2. 토큰 자체에 사용자 식별정보 저장

별도 저장소에 토큰과 사용자 식별정보 저장

사용자가 로그인을 하면 서버는 별도 저장소에 토큰과 사용자 식별자를 저장한다. 이후 클라이언트가 서버에 토큰과 함께 요청을 보내면 서버는 별도 저장소에서 사용자 식별자를 구한다.

서버 메모리에 토큰 정보를 저장할 수도 있다. 톰캣과 같은 서블릿 컨테이너는 메모리에 세션 객체를 저장하는데, 이 세션의 ID가 바로 토큰이 된다.

예를들어 사용자 A가 로그인하면 서버는 사용자 A에게 AAAA라는 세션ID를 발급해준다. 그리고 메모리에 AAAA라는 세션ID를 저장한다. 이후 사용자가 로그아웃하면 서버는 AAAA라는 세션ID를 가진 세션객체를 삭제한다.

추후 A가 로그인하면 서버는 사용자 A에게 또다른 세션ID를 발급해주고 앞서와 같은 방식으로 동작한다.

하지만 토큰 데이터를 이와같이 메모리에 저장하면 1) 서버를 재시작하면 토큰 데이터가 사라지고 2) 메모리 크기에 따라 저장할 수 있는 세션 개수가 한정된다는 단점이 있다. 또한 서버마다 다른 토큰 집합을 저장하고 있기에 sticky session이 필요하다.

이를 보완하기 위해 세션 데이터를 별도 저장소에 보관하기도 한다.

토큰 자체에 사용자 식별정보 저장

JWT를 사용하면 토큰에 사용자 식별자를 저장할 수 있다. 사용자가 로그인에 성공할 경우 사용자 식별자를 포함하는 JWT를 생성해 토큰으로 응답하는 것이다. 이렇게 하면 토큰 정보를 별도 외부 DB에 저장할 필요가 없다. 사용자가 요청을 보낼 때 함께 전송한 토큰을 통해 사용자를 식별할 수 있기 때문이다.

단점은 네트워크 트래픽 증가이다. 토큰 안에 데이터를 넣는 것이기 때문에 서버와 클라이언트가 주고받는 데이터의 크기가 증가하기 때문이다. 그렇기에 토큰에는 최소한의 필요한 데이터만 넣어야 한다. 또 서버에서 토큰 데이터를 제어할 수 없다는 단점도 있다. DB에 토큰을 저장했을 때에는 해당 토큰을 삭제하기만 하는데 이 방법은 클라이언트가 토큰을 가지고 있기 때문이다.

토큰 보안

JWT를 사용하면 토큰에 사용자 식별자를 저장할 수 있다. 사용자가 로그인에 성공할 경우 사용자 식별자를 포함하는 JWT를 생성해 토큰으로 응답하는 것이다. 이렇게 하면 토큰 정보를 별도 외부 DB에 저장할 필요가 없다. 사용자가 요청을 보낼 때 함께 전송한 토큰을 통해 사용자를 식별할 수 있기 때문이다.

단점은 네트워크 트래픽 증가이다. 토큰 안에 데이터를 넣는 것이기 때문에 서버와 클라이언트가 주고받는 데이터의 크기가 증가하기 때문이다. 그렇기에 토큰에는 최소한의 필요한 데이터만 넣어야 한다. 또 서버에서 토큰 데이터를 제어할 수 없다는 단점도 있다. DB에 토큰을 저장했을 때에는 해당 토큰을 삭제하기만 하는데 이 방법은 클라이언트가 토큰을 가지고 있기 때문이다.