개념 및 동작
JWT(JSON Web Token)
JWT는 JSON Web Token의 약자로, 클레임 토큰 기반의 인증 방식이다.
클라이언트의 상태를 세션에 저장하는 세션방식이 아닌, 필요한 정보를 토큰(Token)에 저장해서 증명서처럼 사용한다.
클레임 토큰 기반이라는 뜻은, Claim = 사용자에 대한 property, 정보로, 토큰 자체가 정보인 방식이다.
동작방식
JWT토큰은 위처럼 동작을 한다.
1. 유저가 로그인을 한다.
2. 서버는 로그인 후 사용자의 정보(클레임)를 JWT payload에 담고, 이를 서명하여 JWT 토큰을 생성합니다.
3. 서버는 생성된 JWT 토큰을 클라이언트(일반적으로 브라우저,유저)에게 전달합니다. 이 토큰은 보통 HTTP 헤더의 Authorization 헤더에 담겨서 전송됩니다.
4. 클라이언트가 서버에 요청을 보낼 때, JWT 토큰을 HTTP 헤더의 Authorization 헤더에 담아서 보냅니다.
5. 서버는 클라이언트로부터 받은 JWT 토큰을 검증하고, 필요한 정보를 추출하기 위해 디코딩합니다. 서명이 올바르면 토큰이 유효하다는 것을 의미합니다.
6. 인증된 해당 유저에게 원하는 request(html,css등의 유저가 요청한 화면 및 정보)를 보내줍니다.
이러한 과정을 통해 JWT는 간편하게 사용자 인증과 권한 부여를 처리할 수 있다. 하지만 토큰이 안전하게 전달되고 서명이 유효한지 확인하는 것이 중요하며, 서버 측에서는 보안을 강화하기 위한 적절한 조치를 취해야 한다.
JWT와 관련된 표준으로는 JSON Web Signature (JWS)는 JSON 데이터 구조를 사용하는 서명 표준으로 RFC7515이며, JSON Web Encryption (JWE)는 JSON 데이터 구조를 사용하는 암호화 방법으로 RFC7516 표준이다.
JWS (JSON Web Signature)은 간단히 말하면 “JSON으로 전자 서명을하여 URL-safe 문자열로 표현한 것”이다.
JWE (JSON Web Encryption)는 “JSON을 암호화하여 URL-safe 문자열로 표현한 것” 이다.
서명은 서명 할 때 사용한 키를 사용하여 JSON이 손상되지 않았는지 확인 할 수 있도록하는 것이다.
URL Safe는 말 그대로 URL에 포함 할 수없는 문자를 포함하지 않는 것이다.
JWT의 구조
올바른 형식의 JWT는 점(.)으로 구분된 3개의 연결된 Base64url 인코딩 문자열로 구성된다.
앞부터 {Header}.{payload}.{signature}로 3가지의 정보로 이루어져 있다.
Header
{
"alg": "HS256",
"typ": "JWT"
}
Header는 암호화 작업을 설명하는 매개변수와 사용된 매개변수가 포함된 JSON 개체다. 이름/값 쌍으로 사용하는 해싱 알고리즘과 JWT유형으로 구성된다.
Payload
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Claim, 즉, 사용의 실제정보가 들어가는 곳다. iss (issuer, 토큰 발행자), exp (expiration time, 토큰 만료시간), sub (subject, 토큰 제목), aud(audience, 토큰 대상자), iat(issued at, 토큰의 age 판단)등의 Claim들이 있다.
Signature
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Signature(서명)은 Header에서 명명한 암호화 알고리즘과 Secret Key를 통해서 payload, header에 있는 내용을 담는다. 서명을 통해 토큰이 중간에 바뀌지 않았다는 것을 검증, 증명할 수 있다.
장단점
장점
- 보안에 대한 장점이 있다.
token을 인증 값으로 사용하게 되면 기존 쿠키/세션을 사용하는 방식보다 많은 보안 이슈를 막을 수 있다.
JWT는 쿠키를 사용하지 않기 때문에, CORS이슈가 발생하지 않느낟. - JWT는 XML보다 덜 복잡하고 인코딩 된 사이즈가 적기 때문에 HTTP,HTML 환경에서 사용하기 좋다.
- session의 한계를 극복한다.(세션 정보의 동기화 문제, 웹/앱 간 상이한 쿠키-세션처리 로직, 등등)
단점
- 토큰 자체에 정보가 있다. (장점이자 단점)
- payload 는 인코딩된 데이터로, 중간에 데이터를 탈취해서 디코딩을 하면 데이터를 볼 수 있다.
토큰 자체의 발급처를 알기위한 정보를 담는 용도로 쓰는 것이 좋고, 중요한 데이터는 담지 않는 것이 좋다.
'Backend > 기능 구현' 카테고리의 다른 글
Spring Security JWT - 4. 로그인 세팅 (0) | 2024.01.17 |
---|---|
Spring Security JWT - 2. 프로젝트 생성 및 기본세팅 (0) | 2024.01.16 |
Spring boot - 멀티 모듈 프로젝트를 만들어보자. (1) | 2024.01.02 |