1. 토큰기반 인증의 필요성
최근 토큰기반 인증을 지원하고 권장하는 모듈들이 늘어나고 있다. 토큰기반 인증이 활발하게 사용되기 이전에는(물론 지금도 수많은 곳에서 사용중이다) 세션을 사용한 인증을 사용했다. 세션은 최근 부각되고 있는 마이크로 서비스 측면에서 치명적인 단점을 가지고 있다.
"스케일 인 / 스케일 아웃 등 확장성이 중요한 마이크로서비스 환경에서 세션 유지에 대한 불편함이 있다."
이를 획기적으로 개선할 수 있는 대안이 바로 토큰기반 인증이다.
인증 정보와 기본적인 일부 데이터들을 정해진 시간동안 유효한 토큰으로 만들어 인증에 사용하게 되는데, 이는 서버측 부하를 줄여줄 뿐 아니라 스케일 인 / 스케일 아웃 상황에서 어떤 노드로 커넥션이 옮겨 가더라도 현재의 인증 상태를 유지할 수 있게 된다.
다만 토큰은 서버가 클라이언트의 상태를 확인하고 이를 가지고 있어야 하는 stateful 서비스에는 적합하지 않다.
2. JWT (Json Web Token)
JWT(Json Web Token)은 json string 형태로 되어있는 토큰이다.
JWT이외로 많이 사용되고 있는 Oauth 토큰과의 가장 큰 차이점은 토큰 자체에 정보를 담고있는지에 대한 여부이다. Oauth 토큰의 경우 인증의 유효성 여부만 판단할 수 있기에 만약 서버가 해당 토큰에 담겨있는 인증 사용자의 다른 정보를 확인하기 위해서는 추가적인 서버 작업이 필요하다.
이와는 다르게 JWT의 경우 JSON형식의 토큰 자체에 필요한 정보들이 담겨있기 때문에 인증 외로 필요한 작업들이 있을 때 서버에서 추가 작업이 필요 없다는 장점이 있다.
3. JWT 구성
JWT는 xxx.yyy.zzz 와 같이 . 을 구분자로 3가지 구역으로 나누어져 있다.
3.1. Header
JWT의 가장 앞 구역은 header이다. Header에는 typ(토큰의 타입), alg(해시 알고리즘)을 담고있다.
3.2. Payload
JWT의 중간 부분을 구성하는 Payload(내용)이다.
토큰이 담고있는 정보가 들어있으며 key/value 쌍으로 이루어진 정보 하나 하나를 claim이라고 부른다.
클레임의 종류는 다음과 같이 세가지로 나누어진다.
3.2.1. registered claim
토큰 자체에 대한 정보들을 담고있는 클레임들이다. 미리 정해진 이름들을 사용해야 하지만 필수적으로 필요한 클레임은 없다.
-
iss : 토큰 발급자
-
sub : 토큰의 제목
-
aud : 토큰의 대상
-
exp : 토큰 만료일시
-
nbf : Not Before의 약자이며 지정된 날자가 도달하기 전까지는 토큰이 처리되지 않는다.
-
iat : 토큰이 발행된(issued) 시간을 의미한다.
3.2.2. public claim
public claim은 collision-resistant해야 하며 주로 URL 형식으로 만들어진다.
ex) {"https://leafcats.com/has_role" : true}
3.2.3. private claim
서비스에 필요한 정보들이 저장된다. 해당 사용자의 role, 이름 등 서비스에 사용될 정보들이 저장되어 있다.
3.3. Signature
JWT 마지막 영역은 서명 정보로 이루어져 있다. 서명은 Header의 인코딩된 값과 Payload의 인코딩값을 합친 다음 private key로 해싱 하여 생성된다. 서버는 이를 통해 해당 토큰의 위변조 여부를 판단할 수 있다.
즉, 해커가 header와 payload에 있는 정보를 변조했다 하더라도 서버에서 이를 다시 해싱했을 때 signature 영역과 다르다면 유효한 토큰이 아니라고 판단할 수 있는 것이다.
