JWT와 JWKS — Token을 서명하고 검증하는 방법

앞선 글에서는 Public Key와 Private Key가 하나의 Key Pair로 사용되고, Digital Signature에서는 Private Key로 Signature를 생성하고 Public Key로 이를 검증하는 원리를 살펴봤다.
→ 공개키와 개인키 — 암호화와 디지털 서명의 원리

 

그보다 앞에서는 Token이 Client가 Server에 제시하는 Credential이고, Token의 검증 구조에 따라 Opaque Token과 Self-contained Token으로 나눠볼 수 있다는 점을 살펴봤다.

→ Token 기반 인증 이해하기 — Bearer, Access·Refresh Token

 

이제 이 두 개념을 연결해보자.

Opaque Token은 Token 자체만으로 의미를 알기 어렵기 때문에 Server-side Token Store나 Introspection Endpoint를 통해 상태와 권한을 확인하는 구조를 사용할 수 있다.

Opaque Token → Token Store / Introspection → 사용자와 권한 확인

 

반대로 Token 내부에 Claim을 포함하고, Cryptographic Signature를 이용해 Token이 발급 이후 변경되지 않았는지 검증할 수 있는 구조도 있다.

 

대표적인 형식이 JWT(JSON Web Token)다.

JWT에는 Token의 주체가 누구인지, 누가 발급했는지, 어느 대상을 위한 것인지, 언제 만료되는지 같은 정보를 Claim으로 표현할 수 있다.

JWT는 이러한 Claim을 전달하기 위한 표준 형식이다.

JWT는 JWS를 이용해 서명된 형태로 사용할 수도 있고, JWE를 이용해 암호화된 형태로 사용할 수도 있다.

 

우리가 웹 인증에서 흔히 보는 header.payload.signature 형태는 서명된 JWT를 JWS Compact Serialization으로 표현한 경우다.

 

이번 글에서는 일반적인 웹 인증 시스템에서 자주 사용하는 서명된 JWT를 중심으로 Header, Payload, Signature가 어떤 관계를 가지는지 살펴본다.

 

그리고 Resource Server가 Public Key를 어떻게 얻어 Signature를 검증하고, JWKS를 이용해 여러 Signing Key와 Key Rotation을 어떻게 관리할 수 있는지도 함께 살펴본다.

 

목차

1. JWT는 Claim을 전달하는 Token Format이다
   - Claim
   - Registered Claim
2. 서명된 JWT는 Header, Payload, Signature로 구성된다
   - Header
   - alg에 따라 Key를 사용하는 방식이 달라진다
   - Payload
   - Signature
   - JWS Signing Input
3. Signature는 Header와 Payload의 변조를 검증한다
   - 원본 Signing Input
   - Payload 변경
   - Signature Verification 실패
4. Signature 검증만 성공한다고 Token을 신뢰할 수 있는 것은 아니다
   - Algorithm과 Signature
   - Issuer
   - Audience
   - Expiration과 Not Before
   - Claim과 Scope
5. JWKS는 검증에 사용할 Public Key를 배포한다
   - JWK와 JWKS
   - kid로 Public Key 선택
6. JWKS를 사용하면 로컬 검증과 Key Rotation을 구성할 수 있다
   - Public Key Cache
   - Key Rotation

---

1. JWT는 Claim을 전달하는 Token Format이다

JWT는 인증 방식 자체가 아니다.

• JWT ≠ Login 방식
• JWT ≠ OAuth 2.0
• JWT ≠ OpenID Connect

JWT는 정보를 어떤 구조로 표현하고 전달할 것인지를 정의하는 Token Format이다.

 

예를 들어 Token 안에 다음과 같은 정보를 담을 수 있다.

{ "sub": "user-42", "role": "admin", "iss": "https://auth.example.com", "aud": "api.example.com", "exp": 1760000000 } 

이처럼 JWT 안에 들어가는 각각의 정보를 Claim이라고 한다.

Claim은 Token의 주체, 발급자, 대상 서비스, 만료 시간, 권한 같은 정보를 표현하는 데 사용할 수 있다.

 

Registered Claim

JWT 표준에는 여러 시스템에서 공통적으로 사용할 수 있도록 이름과 의미가 미리 정의된 Registered Claim이 있다.

 

JWT의 주요 Registered Claim

Claim	이름	의미
iss	Issuer	Token을 발급한 주체
sub	Subject	Token이 나타내는 주체
aud	Audience	Token을 사용할 대상으로 지정된 주체
exp	Expiration Time	Token이 만료되는 시간
nbf	Not Before	이 시간 이전에는 Token을 사용할 수 없음
iat	Issued At	Token이 발급된 시간
jti	JWT ID	JWT를 식별하기 위한 ID

모든 JWT가 이 Claim을 전부 사용해야 하는 것은 아니다.

Token의 목적과 시스템의 요구사항에 따라 필요한 Claim을 선택한다.

 

JWT에서 중요한 점은 이런 Claim을 구조화해서 전달할 수 있고, 서명된 JWT에서는 Header와 Payload가 서명 이후 변경되지 않았는지 Cryptographic Signature를 통해 검증할 수 있다는 점이다.

---

2. 서명된 JWT는 Header, Payload, Signature로 구성된다

웹 인증에서 흔히 사용하는 서명된 JWT는 다음과 같은 형태다.

xxxxx.yyyyy.zzzzz 

 

점(.)을 기준으로 세 부분으로 나뉜다.

Header.Payload.Signature 

JWT Header, Payload, Signature 구조

Header

Header에는 JWT를 처리하고 검증하는 데 필요한 메타데이터가 들어간다.

예를 들어 다음과 같은 Header를 사용할 수 있다.

{ "alg": "RS256", "typ": "JWT", "kid": "key-2026-01" } 

항목	의미
alg	서명 또는 MAC에 사용하는 Algorithm
typ	Token Type을 나타내는 값
kid	검증에 사용할 Key를 찾기 위한 Key ID

 

특히 kid는 뒤에서 살펴볼 JWKS에서 여러 Key 중 현재 JWT를 검증할 때 어떤 Key를 사용할지 선택하는 데 활용할 수 있다.

 

alg에 따라 Key를 사용하는 방식이 달라진다

공개키와 개인키 — 암호화와 디지털 서명의 원리에서는 Public Key와 Private Key를 이용한 Digital Signature를 살펴봤다.

하지만 모든 서명된 JWT가 Public Key와 Private Key를 사용하는 것은 아니다.

Header의 alg에 따라 Signature 또는 MAC을 생성하고 검증하는 방식과 필요한 Key 구조가 달라진다.

Algorithm	방식	Key 구조
HS256	HMAC + SHA-256	Shared Secret
RS256	RSA Signature + SHA-256	Private Key + Public Key
ES256	ECDSA + SHA-256	Private Key + Public Key

 

HS256은 HMAC-SHA-256을 사용한다.

Public Key와 Private Key를 사용하는 방식이 아니라 Token을 생성하는 주체와 검증하는 주체가 같은 Shared Secret을 알고 있어야 한다.

• Shared Secret → HMAC 생성
• 같은 Shared Secret → HMAC 검증

반면 RS256과 ES256 같은 비대칭 Signature Algorithm에서는 Private Key와 Public Key의 역할을 분리할 수 있다.

• Private Key → Signature 생성
• Public Key → Signature 검증

이후에는 JWKS와의 관계까지 연결해서 보기 위해 RS256을 사용하는 JWT를 예로 살펴본다.

 

Payload

Payload에는 실제 Claim이 들어간다.

{ "iss": "https://auth.example.com", "sub": "user-42", "aud": "api.example.com", "role": "admin", "exp": 1760000000 } 

 

여기서 중요한 점이 있다.

일반적인 서명 JWT의 Payload는 암호화된 것이 아니다.

Header와 Payload는 Base64url Encoding되어 있기 때문에 Token을 가지고 있다면 내용을 Decode해서 확인할 수 있다.

• Base64url Encoding ≠ Encryption

따라서 Password, Private Key, Secret 같은 민감한 정보를 Payload에 그대로 저장하면 안 된다.

JWT는 JWE를 이용해 암호화하는 구조도 지원하지만, 일반적인 header.payload.signature 형태의 서명 JWT는 Payload의 Confidentiality를 제공하는 구조가 아니다.

 

서명된 JWT에서 Signature의 핵심 역할은 Header와 Payload의 Integrity를 검증할 수 있게 하는 것이다.

 

Signature

마지막 부분은 Signature다.

 

JWS Compact Serialization에서는 Base64url Encoding된 Header와 Payload를 .으로 연결한 값을 Signature 생성과 검증의 입력으로 사용한다.

Base64url(Header) + "." + Base64url(Payload) 

이 값을 JWS Signing Input이라고 볼 수 있다.

즉 JWT에서 Signature가 대상으로 하는 데이터는 Payload만이 아니다.

Header와 Payload를 이용해 만든 Signing Input 전체가 Signature와 연결된다.

 

예를 들어 RS256을 사용한다면 Issuer는 자신의 RSA Private Key를 이용해 Signing Input에 대한 Signature를 생성한다.

JWS Signing Input → RS256 → Private Key → Signature 생성

 

OAuth 2.0 기반 시스템에서는 Authorization Server가 이러한 JWT의 Issuer 역할을 할 수 있다.

 

최종 JWT는 다음 세 부분으로 구성된다.

Header.Payload.Signature 

---

3. Signature는 Header와 Payload의 변조를 검증한다

공개키와 개인키 — 암호화와 디지털 서명의 원리에서 살펴본 Digital Signature의 원리가 JWT에도 그대로 적용된다.

 

차이가 있다면 일반적인 Message 대신 JWT에서는 Header와 Payload를 이용해 만든 JWS Signing Input에 Signature가 연결된다는 점이다.

 

Issuer가 다음 Payload를 포함한 JWT를 발급했다고 하자.

{ "sub": "user-42", "role": "user" } 

 

Header와 Payload를 Base64url Encoding하고 .으로 연결하면 Signing Input이 만들어진다.

Base64url(Header).Base64url(Payload)

Issuer는 이 Signing Input을 기준으로 자신의 Private Key를 사용해 Signature를 생성한다.

 

개념적으로 다음 관계를 가진다.

Signing Input A → Private Key로 서명 → Signature A

 

따라서 정상적인 JWT는 다음 관계를 가진다.

원본 Header + 원본 Payload + Signature A

 

Payload가 변경되면 Signing Input도 달라진다

이제 공격자가 Token을 탈취하고 Payload의 role을 변경한다고 하자.

{ "sub": "user-42", "role": "admin" } 

 

Payload 내용이 변경되면 Base64url Encoding 결과도 달라진다.

따라서 Header와 Payload를 연결해 만든 JWS Signing Input 역시 원본과 달라진다.

원본 Payload → Signing Input A

변조된 Payload → Signing Input B

 

문제는 기존 Signature A가 Signing Input A를 기준으로 Issuer의 Private Key를 이용해 만들어졌다는 점이다.

공격자가 Payload만 변경하고 기존 Signature를 그대로 붙이면 다음 상태가 된다.

변조된 Header.Payload + 기존 Signature A

공격자가 Issuer의 Private Key를 가지고 있지 않다면 변경된 Signing Input에 맞는 새로운 유효한 Signature를 생성할 수 없다.

 

Resource Server는 현재 Signing Input을 기준으로 검증한다

Resource Server는 JWT를 받으면 현재 전달된 Header와 Payload로 Signing Input을 구성하고 Signature를 검증한다.

 

RS256을 사용하는 경우 Resource Server는 Issuer의 Private Key가 아니라 Issuer의 Public Key를 사용한다.

현재 Signing Input + Signature + Issuer의 Public Key → Signature Verification

 

현재 Payload는 이미 변경되었지만 Signature는 원본 Signing Input을 기준으로 만들어진 값이므로 검증에 실패한다.

Signing Input B + Signature A → Signature Verification Failed

즉 Signature의 핵심은 Payload의 내용을 숨기는 것이 아니다.

JWT가 서명된 이후 Header 또는 Payload가 변경되었는지 검증할 수 있게 하는 것이다.

 

JWT Signature 생성과 Payload 변조 검증 흐름

---

4. Signature 검증만 성공한다고 Token을 신뢰할 수 있는 것은 아니다

Resource Server가 다음과 같은 요청을 받았다고 하자.

GET /profile HTTP/1.1 Authorization: Bearer <jwt> 

서명된 JWT를 사용한다면 먼저 Signature가 유효한지 검증해야 한다.

 

RS256 같은 비대칭 Signature Algorithm을 사용한다면 Issuer는 Private Key로 JWT에 서명하고, Resource Server는 Issuer의 Public Key를 이용해 Signature를 검증할 수 있다.

Signature 검증에 성공하면 현재 Header와 Payload에 대해 해당 Signature가 유효하다는 것을 확인할 수 있다.

또 Resource Server가 신뢰하도록 구성한 Issuer의 Public Key를 사용했다면, 대응되는 Private Key를 이용해 이 Signature가 생성되었다는 것을 Cryptographically 검증할 수 있다.

 

하지만 이것만으로 현재 요청에서 Token을 받아들여도 된다는 뜻은 아니다.

정상적인 Signature를 가진 Token이어도 다른 시스템을 대상으로 발급되었거나, 이미 만료되었거나, 현재 API에 필요한 권한이 없을 수 있기 때문이다.

따라서 Signature Verification과 함께 iss, aud, exp, nbf 같은 Claim도 검증해야 한다.

 

Algorithm과 Signature

Resource Server는 애플리케이션이 허용하도록 설정한 Algorithm인지 확인해야 한다.

Token Header에 적힌 alg 값을 보고 무조건 해당 Algorithm을 받아들이는 방식으로 구현하면 안 된다.

Server가 허용할 Algorithm을 미리 제한하고, 해당 정책 안에서 Signature 또는 MAC을 검증해야 한다.

 

Issuer

iss Claim은 Token을 발급한 Issuer를 나타낸다.

{ "iss": "https://auth.example.com" } 

 

Resource Server는 이 값이 자신이 신뢰하도록 설정한 Issuer와 일치하는지 확인해야 한다.

Expected Issuer == Token의 iss

Signature Verification과 Issuer Validation은 연결되어 있지만 같은 검증은 아니다.

Signature Verification은 현재 Token의 Signature가 검증에 사용한 Key에 대해 유효한지 확인한다.

Issuer Validation은 Token의 iss가 애플리케이션이 기대하고 신뢰하는 발급자인지 확인한다.

 

Audience

aud는 이 Token을 어느 대상에서 사용할 수 있도록 발급했는지를 나타낸다.

{ "aud": "api.example.com" } 

Resource Server는 자신이 해당 Token의 Audience인지 확인해야 한다.

 

예를 들어 다음 Token이 있다고 하자.

aud = payment-api 

user-api가 Signature만 정상이라는 이유로 이 Token을 그대로 받아들이면 안 된다.

정상적인 Issuer가 발급한 Token이어도 다른 Resource Server를 대상으로 발급된 Token일 수 있기 때문이다.

 

Expiration과 Not Before

exp는 Token의 만료 시간을 나타낸다.

{ "exp": 1760000000 } 

현재 시간이 exp 이후라면 Token을 더 이상 사용할 수 없도록 처리해야 한다.

nbf가 있다면 현재 시간이 Token을 사용할 수 있는 시점에 도달했는지도 확인해야 한다.

 

Claim과 Scope

Signature와 기본 Claim이 모두 정상이어도 현재 API가 요구하는 권한이 있는지는 별도의 문제다.

예를 들어 API가 profile:write 권한을 요구한다면 Token에 해당 Scope나 권한 정보가 있는지 확인해야 한다.

따라서 JWT 검증은 단순히 다음과 같은 과정이 아니다.

Signature OK → 요청 허용

 

실제로는 여러 검증 단계를 거쳐야 한다.

검증 단계	확인하는 것
Algorithm	허용된 Algorithm인가
Signature	현재 Header와 Payload에 대해 Signature가 유효한가
Issuer	신뢰하는 Issuer가 발급한 Token인가
Audience	현재 Resource Server를 대상으로 발급되었는가
Expiration	Token이 만료되지 않았는가
Not Before	Token을 사용할 수 있는 시간이 되었는가
Claim / Scope	현재 요청에 필요한 권한을 가지고 있는가

 

JWT 검증 전체 흐름

즉 JWT 검증은 크게 Cryptographic Verification과 Application-level Claim Validation으로 나눠서 생각할 수 있다.

---

5. JWKS는 검증에 사용할 Public Key를 배포한다

앞선 글에서는 Public Key를 공개할 수 있다는 것과, 그 Public Key를 특정 주체의 Key라고 신뢰하는 것은 서로 다른 문제라는 점을 살펴봤다.

 

JWT에서도 마찬가지다.

Resource Server가 RS256으로 서명된 JWT를 검증하려면 Issuer의 Public Key가 필요하다.

그리고 그 Public Key를 신뢰할 수 있는 경로를 통해 얻어야 한다.

Public Key 파일을 각 Resource Server에 직접 복사하는 방법도 있다.

 

하지만 서비스가 많아지고 Signing Key가 변경되면 모든 Resource Server의 설정이나 Key 파일을 함께 변경해야 한다.

이런 Cryptographic Key를 JSON 형태로 표현하고 여러 Key를 함께 제공하는 데 사용할 수 있는 표준이 JWK(JSON Web Key)와 JWKS(JSON Web Key Set)다.

 

여기서는 JWT Signature Verification에 필요한 Public Key를 배포하는 용도로 살펴본다.

 

JWK와 JWKS

JWK는 Cryptographic Key를 JSON 객체로 표현하는 형식이다.

예를 들어 RSA Public Key를 다음과 같이 표현할 수 있다.

{ "kty": "RSA", "kid": "key-2026-01", "use": "sig", "alg": "RS256", "n": "...", "e": "AQAB" } 

항목	의미
kty	Key Type
kid	Key를 구분하기 위한 Key ID
use	Key의 용도. 예: sig
alg	해당 Key와 연결해 사용할 Algorithm 정보
n	RSA Modulus
e	RSA Exponent

 

여러 JWK를 하나의 keys 배열에 담은 구조를 JWK Set, 즉 JWKS라고 한다.

{ "keys": [ { "kty": "RSA", "kid": "key-2026-01", "use": "sig", "alg": "RS256", "n": "...", "e": "AQAB" }, { "kty": "RSA", "kid": "key-2026-02", "use": "sig", "alg": "RS256", "n": "...", "e": "AQAB" } ] } 

 

OAuth 2.0이나 OpenID Connect 기반 시스템에서는 Authorization Server가 JWT의 Issuer 역할을 하면서 검증에 필요한 Public Key를 JWKS Endpoint를 통해 제공할 수 있다.

https://auth.example.com/.well-known/jwks.json 

그러면 Resource Server는 이 Endpoint에서 Signature Verification에 사용할 Public Key를 가져올 수 있다.

 

Authorization Server · JWT · JWKS · Resource Server 관계

OpenID Connect에서는 Discovery Metadata의 jwks_uri를 통해 JWK Set의 위치를 제공할 수 있다.

 

kid는 어떤 Public Key를 사용할지 알려준다

Issuer는 하나의 Public Key만 공개할 필요가 없다.

 

Key Rotation 등을 위해 여러 Key가 JWKS에 동시에 존재할 수 있다.

이때 Resource Server는 현재 JWT를 어떤 Public Key로 검증해야 하는지 알아야 한다.

이를 위해 JWT Header의 kid를 사용할 수 있다.

{ "alg": "RS256", "kid": "key-2026-02" } 

 

Resource Server는 JWKS에서 kid=key-2026-02에 해당하는 JWK를 찾는다.

JWT의 kid → JWKS에서 같은 kid 검색 → Public Key 선택 → Signature Verification

kid는 Public Key 자체가 아니다.

여러 Key 중 검증에 사용할 Key를 선택하기 위한 식별자다.

 

또 kid가 있다는 사실 자체가 해당 Key를 신뢰할 수 있다는 의미도 아니다.

Resource Server가 신뢰하도록 구성한 Issuer와 JWKS를 기준으로 적절한 Key를 선택해야 한다.

---

6. JWKS를 사용하면 로컬 검증과 Key Rotation을 구성할 수 있다

서명된 JWT와 JWKS를 함께 사용하는 구조의 특징 중 하나는 Resource Server가 Authorization Server에 매 요청마다 Token 상태를 물어보지 않고 JWT를 검증하는 구조를 만들 수 있다는 점이다.

 

Opaque Token을 중앙 상태 조회 방식으로 사용한다면 요청마다 Token Store나 Introspection Endpoint를 확인하는 구조를 사용할 수 있다.

Opaque Token → Resource Server → Token Store / Introspection → Token 상태 확인

 

반대로 필요한 Claim을 포함한 서명된 JWT를 사용하면 Resource Server가 이미 확보한 검증용 Key를 이용해 Token을 자신의 Process 안에서 검증하는 구조를 만들 수 있다.

JWT → Resource Server → Signature Verification + Claim Validation

이 경우 Authorization Server를 모든 API 요청의 Token Verification Data Path에 직접 포함하지 않아도 된다.

Authorization Server는 Token을 발급하고 검증에 필요한 Public Key를 제공한다.

Resource Server는 전달받은 JWT를 자신의 Process 안에서 검증할 수 있다.

 

Public Key Cache

Resource Server가 JWT를 검증할 때마다 JWKS Endpoint를 호출할 필요는 없다.

일반적으로 JWKS에서 가져온 Public Key를 Cache하고 여러 요청의 Signature Verification에 재사용할 수 있다.

JWKS Endpoint → Public Key 조회 → Resource Server Cache → 여러 JWT 검증

따라서 JWT를 로컬에서 검증한다는 것은 매 요청마다 Authorization Server와 통신하지 않고, Resource Server가 확보한 검증 Key를 이용해 Token의 Signature와 필요한 Claim을 확인한다는 의미다.

 

Key Rotation

Signing Key를 영구적으로 하나만 사용할 필요는 없다.

보안 정책이나 운영 요구에 따라 새로운 Key로 교체할 수 있다.

 

예를 들어 현재 Key A를 사용하고 있다고 하자.

Private Key A Public Key A kid = A 

 

새로운 Key B로 전환하려면 먼저 JWKS에 기존 Public Key A와 새로운 Public Key B를 함께 제공할 수 있다.

JWKS → Public Key A + Public Key B

 

그다음 새로 발급하는 JWT부터 Private Key B로 서명하고 Header에는 새로운 kid=B를 넣는다.

 

기존에 발급된 JWT는 여전히 kid=A를 가지고 있으므로 Resource Server는 JWKS의 Public Key A를 이용해 검증할 수 있다.

새 JWT는 kid=B를 가지고 있기 때문에 Public Key B를 사용한다.

• kid=A → Public Key A
• kid=B → Public Key B

이렇게 기존 Key와 새로운 Key를 일정 기간 함께 제공하면 기존에 발급된 Token의 검증 가능성을 유지하면서 새로운 Signing Key로 전환할 수 있다.

 

일반적인 흐름은 다음과 같이 정리할 수 있다.

1. 기존 Key A로 JWT를 서명하고 있다.
2. 새로운 Key B를 생성하고 Public Key B를 JWKS에 추가한다.
3. 새 JWT부터 Private Key B로 서명하고 kid=B를 사용한다.
4. 기존 Key A로 발급된 JWT를 검증해야 하는 동안 Public Key A도 JWKS에 유지한다.
5. 기존 JWT를 더 이상 검증할 필요가 없게 되면 Public Key A를 JWKS에서 제거한다.

 

JWKS를 이용한 Key Rotation

 

즉 Key Rotation의 핵심은 새 Signing Key로 전환하는 시점과 기존 Token을 검증할 수 있는 기간을 겹치게 만드는 것이다.

---

정리

JWT는 인증 프로토콜 자체가 아니라 Claim을 전달하기 위한 Token Format이다.

 

웹 인증에서 흔히 보는 서명된 JWT는 다음 세 부분으로 구성된다.

Header.Payload.Signature

구성	역할
Header	Algorithm, kid 같은 Token 처리 메타데이터
Payload	Subject, Issuer, Audience, Expiration, 권한 등의 Claim
Signature	현재 Header와 Payload에 대해 Signature가 유효한지 검증할 수 있게 하는 값

 

일반적인 서명 JWT의 Payload는 암호화되지 않는다.

• Base64url Encoding ≠ Encryption

JWT의 Signature는 다음과 같은 JWS Signing Input을 기준으로 생성된다.

Base64url(Header).Base64url(Payload) → JWS Signing Input

따라서 Header나 Payload가 변경되면 Signing Input도 달라지고 기존 Signature와의 Verification이 실패한다.

 

또 모든 JWT가 Public Key와 Private Key를 사용하는 것은 아니다.

• HS256 → Shared Secret을 이용한 HMAC
• RS256 / ES256 → Private Key로 Signature 생성, Public Key로 검증

하지만 Signature만 유효하다고 해서 현재 요청에서 Token을 바로 받아들여서는 안 된다.

허용된 Algorithm인지 확인하고 Signature를 검증한 뒤 다음과 같은 Claim과 권한도 함께 확인해야 한다.

• Issuer
• Audience
• Expiration
• Not Before
• 필요한 Claim과 Scope

JWKS는 Resource Server가 Signature Verification에 사용할 Public Key를 JSON 형태로 제공받을 수 있게 한다.

JWT Header의 kid → JWKS에서 Public Key 선택 → Signature Verification

그리고 여러 Public Key를 JWKS에 함께 제공하면 기존 Token의 검증 가능성을 유지하면서 새로운 Signing Key로 전환하는 Key Rotation을 구성할 수 있다.

 

전체 구조는 다음과 같다.

JWT 발급부터 JWKS를 이용한 검증까지의 전체 흐름

Authorization Server가 JWT의 Issuer 역할을 하는 구조라면 Authorization Server는 Token을 발급하고 Signing Key를 관리하며, Resource Server는 전달받은 Token의 Signature와 Claim을 검증한다.

 

이제 다음 단계에서는 OAuth 2.0과 OpenID Connect에서 Client, Authorization Server, Resource Server가 각각 어떤 역할을 하고 Token이 어떤 경로로 발급되고 사용되는지 알아보자.