JWT(Json Web Token)란?

1. Introduction (소개)

JWT는 JSON 기반의 구조로 클레임을 안전하게 전달하기 위한 압축되지 않은 문자열입니다. 주로 다음 용도로 사용됩니다:

• 인증 및 권한 부여
• 정보 교환

JWT는 서명(Signed) 또는 암호화(Encrypted) 방식으로 보호되며, 서명된 JWT는 무결성 검증을, 암호화된 JWT는 기밀성을 제공합니다.

---

2. JWT 프로세스

클라이언트                            서버
──────────────                        ──────────────
| 사용자 로그인 |     → 로그인 요청 →  | JWT 생성     |
──────────────                        ──────────────
                                           ↓
                              Secret Key로 서명
                                           ↓
──────────────                        ──────────────
| JWT 저장      | ← JWT 응답 ←        | JWT 발급     |
──────────────                        ──────────────

──────────────                        ──────────────
| API 요청      |     → JWT 포함 →    | JWT 검증     |
──────────────                        ──────────────
                                           ↓
                             유효성 체크 (서명/만료)
                                           ↓
──────────────                        ──────────────
| 응답 받음    | ← API 응답 ←         | 데이터 처리  |
──────────────                        ──────────────

 

로그인 전 과정

1. 사용자 요청:
   사용자가 아이디와 비밀번호(또는 소셜 로그인)를 입력하여 서버에 로그인 요청을 보냅니다.
2. JWT 생성:
   서버는 사용자의 로그인 정보를 확인한 뒤, **비밀 키(Secret Key)**를 사용하여 JWT를 생성합니다.
   JWT는 다음과 같은 정보를 담습니다:
   • Header: 사용된 암호화 알고리즘 정보 (예: HS256).
   • Payload: 사용자 정보(예: 사용자 ID, 만료시간 등).
   • Signature: Header와 Payload를 조합하여 Secret Key로 암호화한 값.
3. JWT 전달:
   생성된 JWT를 클라이언트에 전달합니다.
   이 단계까지가 사용자가 JWT를 발급받기 전까지의 과정입니다.

로그인 후 과정

1. JWT 저장:
   클라이언트는 서버로부터 받은 JWT를 로컬 저장소(LocalStorage) 또는 **세션 저장소(SessionStorage)**에 저장합니다.
2. API 요청 시 JWT 사용:
   클라이언트는 API를 호출할 때마다 요청의 헤더에 JWT를 포함시켜 보냅니다.
3. 서버 인증:
   서버는 받은 JWT를 확인합니다. JWT가 올바른 서명인지 확인하고, 만료되지 않았는지 검증한 뒤, 신뢰할 수 있는 요청인지 판단합니다.
4. 응답 반환:
   검증에 성공하면 서버는 요청된 API에 대한 응답을 반환합니다.

 

그런데 로그인 후에 왜 매번 JWT를 헤더에 넣어서 보내야 할까요? 비효율적이라는 생각이 들 수 있습니다. 매번 인증 과정을 거쳐야하는 이유는 HTTP의 특성 때문입니다.

---

3. JWT와 HTTP의 특성

HTTP 프로토콜의 두 가지 중요한 특성은 다음과 같습니다:

1. Connectionless (연결 비유지):
   한 번 통신이 완료되면 서버와 클라이언트 간의 연결이 끊어집니다.
2. Stateless (상태 비유지):
   서버는 이전 요청에 대한 상태를 기억하지 않습니다.
   예를 들어, 사용자가 이미 로그인했다고 해도, 새로운 요청에서는 사용자가 인증된 상태인지 다시 확인해야 합니다.

이러한 특성 때문에 모든 요청마다 사용자가 인증되었는지 확인해야 합니다. 따라서 JWT를 API 요청 헤더에 포함시켜 매번 검증 과정을 거칩니다.

 

이를 해결하기 위해 Access Token과 Refresh Token을 사용합니다. Access Token은 일정 기간 동안 유효하며, 유효 기간이 만료되면 Refresh Token을 사용해 Access Token을 갱신합니다.

 

4. JWT의 구조

JWT는 세 부분으로 나뉩니다:

 

1. Header (헤더):

서명 알고리즘이나 타입(JWT) 같은 정보를 포함.

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

 

 

2. Payload (페이로드): 

사용자의 데이터가 들어갑니다. 여기에는 클레임(Claims)이 포함됩니다:

• 등록된 클레임: iss(발급자), sub(대상자), exp(만료 시간) 등.
• 사용자 정의 클레임: 예를 들어, user_id와 같은 애플리케이션의 커스텀 데이터.

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

 

 

3. Signature (서명): 

JWT의 무결성을 보장하는 부분입니다. Header와 Payload를 Secret Key로 서명합니다.

 

=> 이 각 3개의 부분은

Base64Url로 인코딩되며, 점(.)으로 구분됩니다.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

 

 

5. Access Token과 Refresh Token의 개념

1. Access Token (액세스 토큰)

• Access Token은 클라이언트가 API 요청을 보낼 때 인증을 위해 사용됩니다.
• 특징:
  • 비교적 짧은 유효 기간(예: 15분 ~ 1시간).
  • 서버가 클라이언트의 요청을 신뢰할 수 있도록 만듭니다.
  • 짧은 유효 기간을 통해 보안을 강화하고, 유출 시 피해를 줄입니다.

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

• Refresh Token은 Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용됩니다.
• 특징:
  • 긴 유효 기간(예: 며칠 ~ 몇 주).
  • 클라이언트는 서버에 Refresh Token을 보내 새로운 Access Token을 요청합니다.
  • Refresh Token은 서버에서만 검증되고, 일반적으로 클라이언트에서 로컬로 저장하지 않습니다(보안상 위험).

---

6. Access Token과 Refresh Token의 사용 흐름

1. 사용자가 로그인:
   • 서버는 Access Token과 Refresh Token을 생성하여 클라이언트에 반환.
2. 클라이언트가 API 호출:
   • 클라이언트는 Access Token을 Authorization 헤더에 포함하여 서버에 요청.
3. Access Token 만료:
   • 서버는 만료된 Access Token을 거부.
4. Refresh Token으로 갱신 요청:
   • 클라이언트는 Refresh Token을 사용해 새로운 Access Token을 요청.
5. 새로운 Access Token 발급:
   • 서버는 Refresh Token을 검증하고 새로운 Access Token을 생성하여 반환.