TIL-2024.04.16 - Basic - JWT (JSON Web Token)

 

 

 

질문:

1. JWT 가 뭐야 ?
2. JWT가 어떤 구성을 가지고, 어떻게 작동해 ??
3. 사용하는 이유가 어떻게 되 ?

 

JWT (JSON WEB TOKEN) 정의

- 웹 애플리케이션에서 사용자 인증 및 권한 부여를 위한 토큰 기반 인증 시스템

 

JWT  구성 

- JWT는 세 부분으로 구성: Header, Payload, Signature

 

1. Header

 

- 토큰의 유형과 사용하는 암호화 알고리즘을 지정

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

 

 

 

2. Payload

- 실제로 전송할 데이터를 포함.

- 클레임(claim)이라고도 불리며, 토큰에 담길 정보의 조각들을 의미

- 클레임은 세 가지 유형으로 나뉩니다:

 

   1. Registered Claims: 토큰에 대한 정보를 제공하는 표준 클레임으로 발급자(issuer), 만료 시간(expiration time) 등.

// 1. Registered Claims (표준 클레임)예시


iss (Issuer): 토큰 발급자를 나타냅니다.
// 예시: "iss": "example.com"

exp (Expiration Time): 토큰의 만료 시간을 나타냅니다. 이 시간 이후에는 토큰이 더 이상 유효하지 않습니다.
// 예시: "exp": 1632456000 (UNIX timestamp)

sub (Subject): 토큰이 제어 대상인 주체(Subject)를 나타냅니다.
// 예시: "sub": "user123"

aud (Audience): 토큰의 대상자(Audience)를 나타냅니다.
// 예시: "aud": "myapp"

iat (Issued At): 토큰의 발급 시간을 나타냅니다.
// 예시: "iat": 1632452400 (UNIX timestamp)

 

   2. Public Claims: 사용자가 정의할 수 있는 클레임들로, 충돌을 방지하기 위해 URI 형식으로 정의.

 

// 2. Public Claims (사용자 정의 클레임) 예시 

customData: 사용자 정의 데이터를 포함할 수 있습니다.
예시: "https://example.com/customData": { "role": "admin", "email": "user@example.com" }

 

 

 

 3. Private Claims: 클라이언트와 서버 간 협의된 클레임들로, 사용자 정의 데이터를 포함.

// 3. Private Claims (사용자 정의 협의된 클레임) 예시 

permissions: 사용자의 권한 정보를 포함할 수 있습니다.
예시: "permissions": ["read", "write"]

userInfo: 사용자 정보를 추가로 포함할 수 있습니다.
예시: "userInfo": { "name": "John Doe", "age": 30 }

 

 

 

3. Signature

- 헤더와 페이로드를 인코딩한 후 비밀 키를 사용하여 서명 부분. 

- 이 서명은 토큰이 변조되지 않았음을 증명하고 검증하는 역할.

 

 

JWT 작동 원리  ( feat. Access Token & Refresh Token)

 

 

---

Access Token 과 Refresh Token  > 

1. Access Token (액세스 토큰)

• 역할: 사용자를 인증하고, 인가된 요청을 처리하는 데 사용.
• 특징:
  • 유효 기간이 짧음
  • 보통 사용자의 식별 정보와 권한 정보 등을 포함.
  • 서버는 클라이언트로부터 받은 Access Token의 유효성을 검증하여 요청을 처리.
  • 보안을 위해 HTTPS와 함께 사용하는 것이 좋음.
• 사용 예시:
  • 사용자 로그인 시 서버에서 Access Token을 발급하여 클라이언트에게 전달.
  • 클라이언트는 API 요청 시 Authorization 헤더에 Access Token을 포함하여 요청 보냄 .

2. Refresh Token (리프레시 토큰)

• 역할: (Access Token의 유효 기간이 만료되었을 때) 새로운 Access Token을 발급받기 위해 사용.
• 특징:
  • Access Token의 유효 기간이 만료되면 클라이언트는 Refresh Token을 사용하여 새로운 Access Token을 요청.
  • 일반적으로 Access Token보다 더 긴 유효 기간.
    보안을 강화하기 위해 Refresh Token은 장기간 유효하지만 Access Token은 짧게 유지됩니다.
  • Refresh Token은 일반적으로 보안적으로 중요한 정보이므로 안전한 저장소에 저장.
• 사용 예시:
  • Access Token의 유효 기간이 만료된 경우 클라이언트는 Refresh Token을 사용하여 서버에 새로운 Access Token
  • 서버는 유효한 Refresh Token을 받으면 새로운 Access Token을 발급하여 클라이언트에게 전달.

 

Access Token과 Refresh Token의 관계

• Access Token 유효 기간이 짧고, Refresh Token 유효 기간이 길게 설정: 이렇게 함으로써 Access Token이 유출될 경우에도 짧은 시간 동안만 악용될 수 있도록 보안을 강화.
• Access Token이 만료되면 Refresh Token을 사용하여 갱신: 클라이언트는 유효하지 않은 Access Token을 서버에 보내면 서버는 새로운 Access Token을 발급하는 대신 Refresh Token의 유효성을 검증하고 필요하다면 새로운 Access Token을 발급.

 

 

---

 

 

두 Token  같이 사용하는  이유   > 

1. 보안 강화

• Access Token의 유효 기간 제한: Access Token은 유효 기간이 짧게 설정하여 보안을 강화합니다. Access Token이 유출되더라도 유효 기간이 짧다면 제한된 시간 동안만 악용될 수 있습니다.
• Access Token 주기적 갱신: Access Token이 만료되면 Refresh Token을 사용하여 새로운 Access Token을 발급받습니다. 이는 유효 기간이 짧은 Access Token을 통해 보안을 유지하면서도 사용자의 인증 상태를 지속적으로 유지할 수 있습니다.
• Refresh Token의 안전한 관리: Refresh Token은 보안적으로 중요한 정보이므로 안전한 저장소에 저장하고 사용해야 합니다. 유효 기간이 길고 Access Token 갱신 요청 시 사용되므로, Refresh Token이 유출되더라도 제한된 피해를 입힐 수 있습니다.

2. 사용자 경험 향상

• 인증 지속성 유지: Access Token의 유효 기간이 짧더라도 Refresh Token을 사용하여 새로운 Access Token을 자동으로 발급받으므로, 사용자는 자주 로그인을 다시 하지 않아도 됩니다. 이는 사용자 경험을 향상시킵니다.
• 세션 유지: Refresh Token을 사용하여 Access Token을 갱신하므로, 사용자는 세션 상태를 오랫동안 유지할 수 있습니다. 따라서 사용자가 자주 인증을 반복할 필요가 없어집니다.

3. 보안과 효율성의 균형

• 유연한 보안 정책: Access Token과 Refresh Token의 조합은 보안 정책을 유연하게 조절할 수 있습니다. Access Token은 짧은 유효 기간으로 보안을 강화하고, Refresh Token은 긴 유효 기간으로 사용자 인증을 지속시킵니다.
• 장기간 서비스 이용: Refresh Token을 사용하여 Access Token을 갱신하므로, 사용자는 오랜 시간 동안 서비스를 계속 이용할 수 있습니다.

 

---

 

 

 

두 토큰의 저장 위치  > 

1. Access Token 저장 위치

• 클라이언트의 메모리: Access Token은 주로 클라이언트(웹 브라우저 또는 모바일 앱)의 메모리에 저장됩니다. 클라이언트가 로그인 후 서버로부터 Access Token을 받으면, 보통 메모리에 저장하여 인증이 필요한 요청에 헤더에 포함시켜 서버로 보냅니다.
• 웹 브라우저의 저장소: 웹 애플리케이션에서는 보통 웹 브라우저의 localStorage 또는 sessionStorage에 Access Token을 저장합니다. 이는 클라이언트 측에서 일시적으로 토큰을 보관하는 방법으로, 브라우저 세션 동안 유지됩니다.
• 안전하지 않은 위치에 저장하지 않기: Access Token은 민감한 정보를 포함하고 있으므로, 안전하지 않은 위치에 저장하면 보안에 취약해질 수 있습니다. 따라서 클라이언트 측 저장소(예: localStorage)에 저장할 때는 XSS(Cross-Site Scripting) 공격에 대비하여 적절한 보안 조치를 취해야 합니다.

2. Refresh Token 저장 위치

• 클라이언트의 안전한 저장소: Refresh Token은 주로 클라이언트의 안전한 저장소에 저장됩니다. 이는 클라이언트 측에서 보안적으로 중요한 정보이므로, 보안된 메모리나 안전한 쿠키, 안드로이드/iOS의 안전 저장소 등을 활용할 수 있습니다.
• HTTP Only 쿠키: 웹 애플리케이션에서는 Refresh Token을 서버로부터 받을 때, HTTP Only 플래그가 설정된 쿠키에 저장하는 방법을 사용할 수 있습니다. 이렇게 함으로써 클라이언트 측 JavaScript에서 쿠키에 접근할 수 없어서 XSS 공격에 노출되지 않습니다.
• 안전한 저장소 사용: Refresh Token은 Access Token보다 긴 유효 기간을 가지므로, 클라이언트 측에 안전하게 저장되어야 합니다. 민감한 정보가 포함되어 있으므로 안전한 저장소에 저장하여 보호해야 합니다.

 

---

 

 

 

JWT 사용 이유

1. 간편한 구현과 사용
- 표준화: JWT는 JSON 기반의 표준화된 토큰 형식이므로 구현과 사용이 간편
- 클라이언트 저장: JWT는 클라이언트에 저장되므로 세션 상태를 서버에 저장할 필요가 없어서 서버의 부담을 줄임.

2. 분산 환경과 마이크로서비스 아키텍처 지원
- 분산 환경: JWT는 토큰 자체에 사용자 정보와 권한 정보를 포함하므로 별도의 세션 저장소 없이도 서비스 간에 인증 및 권한을 공유.
- 마이크로서비스 아키텍처: 각 마이크로서비스는 JWT를 통해 인증을 수행할 수 있으며, 서비스 간에 토큰을 전달하여 보안을 유지

3. 확장성과 유연성
- 사용자 정의 클레임: JWT 페이로드에 사용자 정의 클레임을 포함하여 필요한 사용자 데이터를 토큰에 담음.
- 분리된 인증 서버: JWT를 사용하면 인증 서버와 리소스 서버를 분리하여 서비스 확장성을 향상.

4. 보안
- 토큰 서명: JWT는 서명을 통해 토큰의 무결성을 보장, 변조를 방지하고 서버는 비밀 키를 사용하여 토큰을 검증하여 안전한 통신을 보장.
- OAuth와의 통합: OAuth 2.0 인증 프로토콜과 함께 사용될 수 있어 보안적인 요구사항을 충족시켜, 서비스 간 인증을 통합

5. RESTful API 및 Single Sign-On (SSO) 지원
- RESTful API: JWT는 RESTful API에서 자주 사용되며, HTTP 헤더 또는 URL 매개변수로 토큰을 전송하여 인증을 수행.
- SSO: JWT를 사용하면 다양한 서비스 간에 Single Sign-On을 구현할 수 있어 사용자 경험을 향상시키고 보안을 강화

 

 

 

답변:

1. JWT 가 뭐야 ?
   -  토큰 기반 인증 시스템
   
   
2. JWT가 어떤 구성을 가지고, 어떻게 작동해 ??
   - 토큰의 정보를 지닌 Header, 사용자가 정의한 Claims, 클라이언트&서버간 정의한 Payload로 구성
   
   
3. 어떻게 작동해 ? 
   - 로그인시, 짧은 유통 기간을 가진 Access Token을 발급함
   -  Client는 해당 Token을 웹 브라우저에 저장해놓고 사용하는데, Request 보낼때 같이 해당 정보값을 보냄
   - 만약 유효한 Access Token이면, 옳바른 Response로 응답하지만, 아닐 경우 Access Token이 만료되었다는 신호를 보냄. 
   - 해당 신호를 받으면, Access Token 재발급을 요청하는데, 이때 Refresh Token을 사용해서 재발급
   
   
4. 왜 사용해 ?
   - 구현 및 사용이 간편하고 보안이 안전함 
   - 높은 확장성과 유연성

 

 

 

새로운 질문 :

(SSO: JWT를 사용하면 다양한 서비스 간에 Single Sign-On을 구현할 수 있어 사용자 경험을 향상시키고 보안을 강화 ) 중에서.. 

 

1. SSO (Single Sign-On) 가 뭐야? 

2. 어떻게 JWT로 SSO을 구현할 수 있어 ? (공유 방법)