[JWT] JSON Web Token - With JWT.io

JWT 인증 인가 서비스에 대한 정리가 필요하다 생각하여 작성한 포스팅입니다.
공식문서를 기반으로 한 정리 내용입니다.
부족한 점에 대한 지적은 언제든지 환영합니다!

 

Intro

https://jwt.io/introduction

JWT.IO

공식문서에 의하면 JWT란 JSON Web Token의 줄임말로써, 당사자 간에 정보를 JSON 개체로 안전하게 전송하기 위한 간결하고 독립적인 방법을 정의하는 개방형 표준( RFC 7519 )입니다.

또한 해당 토큰 정보는 디지털 서명이 되어있으므로 확인하고 신뢰할 수 있습니다.

 

로그인 상태 유지를 위해 세션 또는 쿠키를 사용하여 클라이언트의 로그인 요청을 기억하고 상태 유지를 할 수 있지만, 두 가지 방식은 각각의 단점을 가지고 있습니다.

 

다음은 두 가지 차이에 대한 정리 포스팅입니다.

https://infinitecode.tistory.com/67

세션(Session) & 쿠키(Cookie)

 

 

---

JWT는 언제 사용하나?

승인

JWT를 사용하는 가장 일반적인 시나리오로써 사용자가 로그인하면 각 후속 요청에 JWT가 포함되어 사용자가 해당 토큰으로 허용되는 경로, 서비스 및 리소스에 엑세스할 수 있습니다.

Single Sign On(SSO)는 오버헤드가 적고 다양한 도메인에서 쉽게 사용할 수 있다는 점 때문에 JWT를 널리 사용하는 기능입니다.

SSO란 ?

SSO는 Single Sign-On의 약자로, 여러 애플리케이션 또는 시스템에 한 번 로그인하면 다른 시스템에도 자동으로 로그인되는 인증 방식입니다. 즉, 사용자는 각 시스템마다 개별 로그인을 할 필요 없이, 단 한 번의 로그인 과정으로 여러 시스템에 접근할 수 있습니다.

---

정보 교환

JWT는 당사자 간에 정보를 안전하게 전송하는 좋은 방법입니다.

예를 들어 공개/개인 키 쌍을 사용하여 JWT에 서명할 수 있으므로 보낸 사람이 누구인지 확인할 수 있습니다.

또한 헤더와 페이로드를 사용해 서명을 계산하므로 컨텐츠가 변조되지 않았는지 확인할 수도 있습니다.

 

---

JWT 구조

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

JWT(JSON Web Token)는 세 부분으로 구성되며, 이 세 부분은 점 (.)으로 구분됩니다.

세 부분은 다음과 같습니다

Header

Payload

Signature

따라서 JWT는 일반적으로 다음과 같습니다.

xxxxx.yyyyy.zzzzz

 

다음은 각 구성요소에 대한 상세한 내용입니다.

Header

헤더는 일반적으로 토큰 유형과 사용되는 서명 알고리즘(예 : HMAC SHA256)의 두 부분으로 구성됩니다.

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

해당 JSON은 Base64Url로 인코딩되어 JWT의 첫 번째 부분을 구성합니다.

 

Payload

토큰의 두 번째 부분은 클레임을 포함하는 페이로드입니다.

페이로드의 예는 다음과 같습니다.

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

 

클레임(Claims)?

클레임은 사용자 정보, 토큰 만료 시간, 발급자 정보 등을 포함하는 JSON 형식의 데이터입니다. 클레임에는 다음과 같은 세 가지 유형이 있습니다.

등록된 클레임

유용하고 상호 운용 가능한 클레임 집합을 제공하기 위해 필수는 아니지만 권장되는 미리 정의된 클레임 집합입니다.

그 중 일부는 iss(발행자), exp(만료 시간), sub(주제), aud(청중) 등이 있습니다.

공개 청구

JWT를 사용하는 사람들이 원하는 대로 정의할 수 있습니다. 그러나 충돌을 방지하려면 IANA JSON 웹 토큰 레지스트리에 정의하거나 충돌 방지 네임스페이스를 포함하는 URI로 정의해야 합니다.

비공개 클레임

사용에 동의한 당사자 간에 정보를 공유하기 위해 생성된 맞춤 클레임으로, 등록되거나 공개된 클레임이 아닙니다.

 

주의할 점은 서명된 토큰의 경우 페이로드 정보는 변조로부터 보호되지만 누구나 읽을 수 있습니다. 암호화되지 않은 경우 헤더 또는 페이로드에 비밀 정보를 넣지 말아야 합니다.

 

Signature

서명 부분을 생성하려면 인코딩된 헤더, 인코딩된 페이로드, 비밀 키(SHA256 등), 헤더에 지정된 알고리즘을 가져와서 서명해야 합니다.

서명의 예로 HMAC SHA256 알고리즘을 사용하는 경우 다음과 같은 방식으로 생성됩니다.

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

서명은 메시지가 도중에 변경되지 않았는지 확인하는 데 사용되며, 개인 키로 서명된 토큰의 경우 JWT의 보낸 사람이 누구인지 확인할 수도 있습니다.

 

출력은 HTML 및 HTTP환경에서 쉽게 전달할 수 있는 점(.)으로 구분된 3개의 Base64-URL문자열이며, SAML과 같은 XML 기반 표준과 비교할 때 더 간결합니다.

다음 사이트에서 JWT를 디코딩, 확인 및 생성할 수 있습니다.

https://jwt.io/#debugger-io

JWT.IO

 

---

JWT 작동 방식

인증 시 사용자가 자격 증명을 사용하여 성공적으로 로그인하면 JSON 웹 토큰이 반환됩니다.
토큰은 자격 증명이므로 보안 문제를 방지하기 위해 세심한 주의를 기울여야 합니다.
일반적으로 토큰을 필요한 것보다 오래 보관하면 안 됩니다. ( -> Refresh Token을 사용 )
또한 보안이 부족하므로 민감한 세션 데이터를 브라우저 저장소에 저장해서는 안 됩니다 .
사용자가 보호된 경로에 액세스하려고 할 때마다 일반적으로 Bearer 스키마 를 사용하여 Authorization 헤더 에 JWT를 보내야 합니다.

따라서 헤더의 내용은 다음과 같아야 합니다.
Authorization: Bearer <token>

사용자 상태는 서버 메모리에 저장되지 않으므로 이는 상태 비저장 인증 메커니즘입니다.
서버의 보호된 경로는 Authorization 헤더에서 유효한 JWT를 확인하고, 있는 경우 사용자를 허용합니다.
JWT는 자체 포함되어 있으므로 필요한 모든 정보가 있으므로 데이터베이스로 왔다 갔다 할 필요성이 줄어듭니다.
이를 통해 상태 비저장 데이터 API에 전적으로 의존하고 다운스트림 서비스에 요청할 수도 있습니다.

 

---

JWT를 사용하는 이유

1. 간편하고 효율적

세션 관리 없이 사용자 인증을 수행할 수 있습니다.

토큰 자체에 사용자 정보를 포함하고 서명하여 간편하게 사용자 식별이 가능합니다.

세션 관리가 없으므로 서버 부하를 줄이고 확장성을 높일 수 있습니다.

2. 높은 보안

디지털 서명으로 보호되어 위변조 및  변조를 방지합니다.

토큰 만료 시간을 설정하여 보안을 강화할 수 있습니다.

다양한 암호화 알고리즘을 사용하여 보안 수준을 조정할 수 있습니다.

3. 다양한 환경에서 사용 가능

RESTful API, 웹 애플리케이션, 모바일 애플리케이션 등 다양한 환경에서 사용할 수 있습니다.

자체 포함형 특성으로 마이크로서비스 아키텍처와 같은 분산 환경에 적합합니다.

다양한 프로그래밍 언어에서 지원됩니다.

4. 정보 전달

사용자 식별 정보뿐만 아니라 추가적인 정보를 포함할 수 있습니다. ( 예로 권한, 프로필 정보 등등이 있습니다.)

 

---

JWT 사용 시 주의점

1. 비밀 키 관리 : 서명 검증에 사용되는 비밀 키를 안전하게 보관해야 합니다.

2. 토큰 만료 기간 설정 : 토큰 만료 시간을 적절하게 설정하여 보안을 유지해야 합니다.

3. 토큰 크기 : 토큰 크기가 클 경우 성능 저하를 초래할 수 있습니다.