페이지의 회원가입 및 로그인을 구현하는 과정에서(실제로 사용되지는 않았음.)의 궁금했던 개념들에 대해 정리해보았다.

JWT(JSON Web Token)란?

JSON 객체를 사용하여 두 시스템 간에 정보를 안전하게 전송하기 위한 컴팩트하고 독립적인 방법을 제공한다. 주로 인증과 정보 교환 목적으로 사용된다.

JWT의 구성요소

1. 헤더(Header)
2. 페이로드(Payload)
3. 서명(Signature)

1. 헤더(Header)

토큰의 유형(JWT)과 사용할 서명 알고리즘(예: HMAC SHA256 또는 RSA)을 지정한다.

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

이러한 JSON 객체를 Base64Url로 인코딩하여 JWT의 첫 번째 부분을 만든다.

2. 페이로드(Payload)

토큰의 클레임(claims)을 포함한다. 클레임은 정보의 조각을 나타내며, 크게 세 가지로 분류된다.

• 등록된 클레임(Registered Claims): 표준화된 클레임으로, iss (발행자), exp (만료 시간), sub (주제), aud (청중) 등이 포함된다.
• 공개 클레임(Public Claims): 충돌 방지를 위해 IANA JSON Web Token Registry에 정의되거나 사용자 정의 클레임이다.
• 비공개 클레임(Private Claims): 사용자 간에 동의된 클레임으로, 공개 클레임과 비슷하지만 IANA에 등록되지 않는다.

예시 페이로드:

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

이 JSON 객체 역시 Base64Url로 인코딩하여 JWT의 두 번째 부분을 만든다.

2. 서명(Signature)

JWT의 무결성을 보호한다.

무결성: 데이터의 정확성, 일관성, 유효성이 유지되는 것

서명을 생성하려면 인코딩된 헤더, 인코딩된 페이로드, 그리고 비밀 키를 조합하여 서명 알고리즘을 통해 생성한다.

예를 들어 HMAC SHA256 알고리즘을 사용할 경우:

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

서명 부분은 JWT의 세 번째 부분이 된다.

JWT의 전체 구조

결국, JWT는 다음과 같이 구성된다.

header.payload.signature

JWT의 사용

1. 인증(Authentication)

• 사용자가 로그인하면 서버는 사용자 정보를 기반으로 JWT를 생성하고 이를 클라이언트에 전달한다.
• 클라이언트는 이후 요청마다 JWT를 포함하여 서버에 인증 요청을 보낸다.
• 서버는 JWT를 검증하여 사용자 인증을 처리한다.

2. 정보 교환(Information Exchange)

• 클라이언트와 서버 간의 정보 교환 시 JWT를 사용하여 안전하게 정보를 전송할 수 있다.
• 서명이 포함되어 있어 정보의 무결성과 신뢰성을 검증할 수 있다.

한편, 앞에서 언급했듯이 JWT의 페이로드에는 토큰의 정보를 포함한 클레임이 들어있다. 페이로드에는 사용자가 인증된 후 서버가 클라이언트에게 전달하는 중요한 정보들이 들어있다.

이 정보는 주로 사용자의 세부 사항, 권한, 토큰의 기타 메타데이터들을 담고 있다.

페이로드의 정보 보호

페이로드에 포함된 정보는 Base64Url로 인코딩되어 토큰의 일부가 되지만, 암호화되지는 않는다. 이는 누구나 토큰을 디코딩하여 페이로드의 내용을 읽을 수 있다는 것을 의미한다. 따라서 민감한 정보(민감한 사용자 식별 정보나 사용자의 권한 여부 등)는 페이로드에 포함시키지 않는 것이 좋다. 민감한 정보를 페이로드에 포함시켜야 할 경우 추가적인 보안 조치가 필요하다.