JWT

들어가기 전

HTTP

쿠키, Cookie

세션, Session

인증, Authentication

인가, Authorization

세션 기반 인증

1. 클라이언트가 ID/PW 로그인을 한다.

2. 서버에서 데이터베이스를 통해 ID/PW를 검증한다.

3. 서버에서 클라이언트의 세션 ID를 발급한 뒤 Session storage에 저장한다.

4. 서버에서 쿠키에 발급한 세션 ID를 담아 클라이언트에게 응답한다.

5. 이후 클라이언트의 요청이 들어올 때마다 서버는 쿠키에 담긴 세션 ID를 검증한 후 응답한다.

토큰 기반 인증

1. 클라이언트가 ID/PW 로그인을 한다.

2. 서버에서 데이터베이스를 통해 ID/PW를 검증한다.

3. 서버에서 인증에 필요한 클라이언트의 정보로 토큰을 발행한 뒤 클라이언트에게 전달한다.

4. 클라이언트는 토큰을 웹 저장소에 보관하여, 이후 인증이 필요한 요청 시 토큰을 저장소에서 꺼내 HTTP Authorization header에 담아 요청한다. 서버에서는 토큰을 검증한 뒤 응답한다.

JWT, JSON Web Token

JWT 구조

헤더

{
  "alg": "HS256",
  "typ": "JWT"
}

페이로드

1. Registered claims

2. Public claims

3. Private claims

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

서명

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secretkey)

JWT 장단점

장점

1. 토큰 기반 인증이므로 서버에서는 인증 정보에 대한 별도의 저장소가 필요 없고 stateless해진다.

2. JWT이 유효한 토큰인지 검증할 수 있는 값들을 자체적으로 담고 있다.

3. JSON 형식이기에 다른 토큰 방식보다 데이터의 크기가 작고 간결하다. (세션 기반 인증보다는 크다)

단점

1. 페이로드에 담긴 데이터는 암호화되지 않고 base64로 인코딩된 값으로 누구나 접근할 수 있다. 그러므로 민감한 정보를 담아서는 안 된다.

2. 서명에 사용한 서버의 시크릿 키가 유출되면 이를 이용해 페이로드 값을 변조하여 유효한 토큰을 생성할 수 있다.

3. 무상태성이므로 악성 유저가 JWT를 갈취하여 요청해도 서버에서는 식별할 수 없고 해당 토큰을 무효화할 수 없다.

4. 무상태성이므로 서버에서 클라이언트의 접속을 강제로 끊을 수 없다.

JWT 보안 전략

토큰의 만료기간을 짧게 설정하기

Refresh Token

Refresh Token Rotation 기법

1. 🎅🏼 사용자가 로그인하여 Access Token(1)과 Refresh Token(1)을 발급받았다.

2. 😈 악성 사용자가 🎅🏼 사용자의 Refresh Token(1)을 갈취했다.

3. 🎅🏼 사용자의 Access Token(1)이 만료되어 Refresh Token(1)으로 서버에 재발급을 요청하여 Access Token(2)와 Refresh Token(2)을 발급받았다.

4. 😈 악성 사용자가 Refresh Token(1)로 서버에 Access Token 재발급을 요청한다.

5. 서버에서는 Refresh Token(1)의 재사용을 감지하고 갈취되었음을 알 수 있다. Refresh Token(1)과 Refresh Token(2) 모두 유효하지 않은 토큰으로 판단한다.

6. 이후 🎅🏼 사용자와 😈 악성 사용자의 Refresh Token으로는 Access Token을 재발급받을 수 없다. 즉 🎅🏼 사용자는 다시 로그인하여 유효한 Refresh Token을 발급받아야 한다.

참고