JWT

홈페이지

JWT.IO

JWT란?

Json Web Token

인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰

공개 / 개인 키를 쌍으로 사용하여 서명할 경우, 서명된 토큰은 개인 키를 보유한 서버가 이 서명된 토큰이 정상적인 토큰인지 인증할 수 있다.

구조

Header . Payload . Signature

HEADER

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

• typ: 토큰의 타입
• alg: 암호화 알고리즘

Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

• iss ( Issuer ) : 토큰 발급자
• sub ( Subject ) : 토큰 제목
• aud ( Audience ) : 토큰 대상자
• exp ( Expiration Time ) : 토큰 만료 시간
• nbf ( Not Before ) : 토큰 활성 날짜
• iat ( Issued At ) : 토큰 발급 시간
• jti ( JWT id ) : 토큰 식별자
• other values : 원하는 값

주의! 패스워드같이 민감한 정보는 담지 말아야한다.

Signature

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  my-256-bit-secret
)

인증

• JWT 토큰을 클라이언트가 서버로 요청과 동시에 전달
• 서버가 가지고 있는 개인키를 가지고 Signature를 복호화한 다음, header와 payload를 비교.

장점

• Session 방식과 다르게 서버에서 별도의 저장소가 필요하지 않다.
• Signature을 개인키 암호화를 통해 막아두었기 때문에 데이터에 대한 보완성이 늘어남.
• 다른 서비스를 확장할때 공통된 스펙으로써 사용할 수 있다.

단점

• Session 방식과 다르게 base64 인코딩을 통한 정보를 전달하므로 전달량이 많다.
• 토큰이 탈취당하면 만료될 때까지 대처가 불가능하다.
  • exp ( Expiration Time ) 을 짧게 가져가야만 한다.

보완

Sliding Session

특정한 서비스를 계속 사용하고 있는 특정 유저에 대해 만료 시간을 연장시켜줌.

Refresh Token

1. 서버에서 JWT를 생성할때 Access Token과 Refresh Token을 생성하여
   클라이언트에게 Access Token과 Refresh Token을 보냄.
   서버는 Refresh Token을 Storage에 저장.
2. 요청을 하던 도중 Access Token이 만료되면 서버는 만료 신호를 보냄
3. 만료 신호를 받은 클라이언트는 Refresh Token을 Server에게 보냄
4. 클라이언트에서 온 Refresh Token을 저장된 Token과 비교하여 맞으면
   Access Token을 새로 발급하여 클라이언트에게 보냄.

참고자료

https://brunch.co.kr/@jinyoungchoi95/1