[데브코스] Spring Security - 7

W17D1 - JWT에 대해 알아보자

JWT

• JSON 포맷을 사용하여 데이터를 만들기 위한 웹 표준 (RFC 7519)
• JWT는 자체적으로 필요한 모든 정보를 지니고 있다. (self-contained)
  • 토큰에 대한 메타정보 (토큰타입, 사용된 해시 알고리즘)
  • 사용자 정의 데이터
  • 토큰 유휴성 검증을 위한 데이터
• 인터넷상에서 쉽게 전달할 수 있음
  • URL-Safe 텍스트로 구성되기 때문에 HTTP 프로토콜의 어느 위치에든 들어갈 수 있음 (보통 HTTP 헤더에 들어감)
• 위변조 검증 가능
  • 토큰이 위변조되지 않았음을 증명하는 서명(Signature) 포함

구조

• Header, Payload, Signature 세 부분으로 구성되고, Base64 Url-Safe 방식으로 인코딩 -> dot(.)을 구분자로 결합함

• Header — JWT를 검증하는데 필요한 정보를 담고 있음 (토큰 타입, 사용된 알고리즘)
  • 알고리즘은 HMAC, RSA 방식을 지원
  • 아래 그림에서 HS512는 HMAC using SHA-512를 의미
  • HMAC 알고리즘에서 비밀키는 최소한 알고리즘의 서명 길이만큼의 비트를 가지고 있어야함 (HS512 — 64byte)
• Payload
  • JWT를 통해 전달하고자 하는 데이터 — Claim-Set 이라고 함
    • Claim 자체는 쉽게 말해 Key-Value 데이터 쌍을 의미함
  • JWT 자체는 암호화되는 것이 아니기 때문에 민감정보를 포함해서는 안됨
  • Reserved Claims, Public Claims, Custom Claims 으로 구분됨
    • Reserved Claims — 미리 등록된 Claims 필수적으로 사용할 필요는 없지만 사용을 권고함
      • iss : 토큰을 발급한 발급자 (Issuer)
      • exp : 만료시간이 지난 토큰은 사용불가
      • nbf : Not Before의 의미로 해당 시간 이전에는 토큰 사용불가
      • iat : 토큰이 발급된 시각
      • jti : JWT ID로 토큰에 대한 식별자
    • Public Claims — 사용자 마음대로 쓸 수 있으나 충돌 방지를 위해 미리 정의된 이름으로 사용을 권고함
    • Custom Claims — 사용자 정의 Claims (Reserved, Public 에 정의된 이름과 중복되지 않도록함)
• Signature
  • 토큰 생성 주체만 알고 있는 비밀키를 이용해 헤더에 정의된 알고리즘으로 서명된 값
  • 토큰이 위변조 되지 않았음을 증명함

인증 과정

1. 사용자의 인증요청
2. 서버에서 요청을 받고 비번 검증후 JWT를 반환
3. 사용자의 브라우저에서 해당 JWT를 저장하고 매 요청시마다 HTTP 헤더에 JWT를 넣어서 보냄
4. 서버는 JWT 유효성 검사 후 요청 수락

Session vs JWT

• Session은 Stateful하고 JWT는 Stateless함
• 따라서 Stateless 상태를 지향하는 Rest API에서는 JWT가 더 적합하다
• 하지만 JWT는 Session보다는 보안이 약하며 다중 로그인 컨트롤, 사용자 유효성 체크, 강제 로그아웃 기능 구현이 어려운 단점이 있음