세션과 JWT
JWT는 세션의 한계를 극복하기 위해 만들어졌습니다. 그렇다면 세션은 무엇이고, 어떠한 한계가 있을까요? 세션과 JWT를 아래와 같은 목차로 알아보도록 하겠습니다.
- 세션
- Embedded Tomcat의 세션
- 세션의 한계와 JWT 탄생
- JWT ( +JWT 구조)
1. 세션
HTTP는 클라이언트와 서버의 통신이 독립적으로 이루어집니다. 즉, 이전의 요청에 무관한 응답을 보내는데 이러한 특성 때문에 Stateless한 프로토콜이라고 합니다.
로그인 기능을 구현하기 위해서는 각각의 요청에 대해서 서버가 사용자를 식별할 수 있어야 합니다. 하지만 HTTP의 Stateless 특성으로 인해 사용자를 식별할 수 없습니다. 이를 해결하기 위해 세션이 탄생되었습니다.
2. Embedded Tomcat의 세션
세션은 앞서 설명과 같이 사용자를 식별하기 위해 사용됩니다. Embedded Tomcat이 사용자를 식별하는 과정을 통해 세션이 동작하는 방식을 이해할 수 있습니다.
| 1. | 클라이언트가 인증을 시도한다. |
| 2. | 인증된 사용자라면 Embedded Tomcat은 고유한 세션 ID (JSESSIONID)를 클라이언트에게 전달한다. |
| 3. | 클라이언트는 JSESSIONID를 쿠키, 로컬 스토리지에 저장한다. |
| 4. | 클라이언트는 서버에 요청 시 JSESSIONID를 함께 전달한다. |
| 5. | 서버에 저장되어 있는 JSESSIONID와 클라이언트가 보낸 JSESSIONID를 비교해 클라이언트의 상태를 확인한다. |
3. 세션의 한계와 JWT 탄생
만약, 여러개의 서버를 증설하면서 로드밸런서를 이용해 트래픽을 분산하였을 경우, 각각 서버는 세션의 정보를 공유하고 있지 않기 때문에 사용자를 식별할 수 없는 문제가 발생합니다.
[트래픽 분산 시 사용자를 식별할 수 없음]
이를 해결하기 위해서는 서버와 공유하고 있는 별도의 세션 저장소를 구축하여야 하는데, 이 때 세션 저장소에 과도한 부하가 발생할 수 있습니다. (세션의 한계) JWT는 이러한 세션의 한계를 극복하고자 탄생되었습니다.
[세션 저장소를 공유함으로써 문제를 해결할 수 있음]
4. JWT
JWT는 매번 저장소에서 사용자의 식별 정보를 조회해야 하는 세션과 달리 별도의 저장소 조회 없이 토큰 그 자체로 인증, 인가를 구현할 수 있습니다. 다시말해 각각의 서버가 하나의 저장소를 공유하지 않아도 자체적으로 사용자를 식별할 수 있습니다.
4.1 JWT 구조
어떻게 JWT는 토큰 그 자체로 인증, 인가를 구현할 수 있을까요? JWT의 구조와 원리를 알아봅시다. JWT는 Header, Payload, Signature 로 구성되어 있습니다.
Header
먼저, Header는 JWT가 어떤 해시 알고리즘으로 토큰을 만들고 있는지에 대한 정보를 담습니다.
- alg: 해시 알고리즘
- typ: 토큰의 타입
Payload
그 다음 Payload에 사용자를 식별할 수 있는 정보를 담습니다. Payload에 담겨있는 각각의 정보를 클레임이라 부릅니다. 클레임은 Registered, Public, Private가 있습니다.
Registered 클레임
토큰 자체의 정보를 담는 클레임입니다. Registered 클레임은 이미 정해진 이름이 있으며 모두 Optional입니다.
| iss | (issuer) 토큰 발급자 |
| sub | (subject) 토큰 제목 |
| aud | (audience) 토큰 대상자 |
| exp | (expiration) 토큰 만료 시간 |
| nbf | (Not Before)을 의미하고 정해진 시간에 토큰을 활성화하기 위해 사용합니다. |
| iat | (issued at) 토큰이 발급된 시간 |
| jti | (JWT ID) JWT 고유 식별자 |
public 클레임
토큰의 충돌을 막기 위해 담는 클레임입니다.
Private 클레임
서버와 클라이언트 간의 사용자 식별을 위해 담는 클레임입니다.
정해진 이름이 없으며 서버와 클라이언트간의 약속으로 클레임을 만듭니다.
Signature
Signature는 JWT의 핵심으로 Signature는 부인 방지, 무결성, 사용자 식별을 담당합니다. 이로 인해 인증, 인가를 구현할 수 있습니다.
Signature 원리
JWT 자체로 인증, 인가를 구현할 수 있었던 비밀은 Signature 때문입니다.
Signature는 토큰 그 자체로 변조되지 않고 유효한 토큰임을 증명합니다. Signature는 어떻게 동작하는 것일까요?
- Header + Payload + 서버만 알고 있는 Secret Key 를 묶어 Header에 선언되어 있는 해시 알고리즘으로 해싱을 진행합니다.
- 위에서 해싱된 결과와 JWT Signature를 비교해 일치하는지 확인합니다.
- 일치한다면 토큰이 유효합니다.
Signature로 토큰이 유효한지만을 증명합니다. 서버는 Payload에 담겨있는 토큰 발급자, 토큰 대상자, 토큰 만료 시간 등을 최종 확인해 인증, 인가를 합니다.
정리
세션의 어떠한 한계로 인해 JWT가 탄생되었는지 또 JWT는 어떻게 세션의 한계를 극복해 별도의 저장소 없이 유효함을 증명할 수 있었는지에 대해 알아보았습니다. JWT를 이해하는데 많은 도움이 되었으면 합니다.
레퍼런스
