JWT Profile / Bearer Token Flow
Secure server-to-server authorization using cryptographically signed JSON Web Tokens (assertions) as authorization grants or client authentication credentials.
Présentation
Defined in RFC 7523, the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants allows client applications to use signed JSON Web Tokens (JWTs) as an authorization grant or client credentials.
Instead of transmitting a static shared client secret over the network (as in standard Client Credentials), the client generates a short-lived JWT assertion containing claims like issuer (iss), subject (sub), audience (aud), and expiration time (exp). The client signs this assertion with its private asymmetric cryptographic key (RS256, ES256, or Ed25519).
The authorization server verifies the assertion signature using the client pre-registered public key or JWKS (JSON Web Key Set). This pattern eliminates shared secret leakage risks and is widely adopted by Google Cloud Service Accounts, Kubernetes Workload Identity, and enterprise federation.
Quick Specifications
- Flow Status
- standard
- Recommended For
- Machine to Machine
- Token Auth Methods
- None
- Primary Standard
- RFC 7523
Diagramme de séquence
Visual sequence illustrating entity interactions and protocol steps
sequenceDiagram
autonumber
participant S as Client Service / Backend
participant AS as Authorization Server (IdP)
participant RS as Resource Server (API)
S->>S: Construct JWT assertion: {iss, sub, aud, exp, jti}
S->>S: Sign assertion with Private Key (RS256 / ES256)
S->>AS: POST /oauth/token (grant_type=jwt-bearer, assertion=SIGNED_JWT)
AS->>AS: Verify signature using client's Public Key (JWKS)
AS->>AS: Validate claims (aud, exp <= 5min, replay protection)
AS-->>S: 200 OK (access_token, token_type=Bearer, expires_in=3600)
S->>RS: Request Data (Authorization: Bearer ACCESS_TOKEN)
RS-->>S: 200 OK (Resource Response)Déroulement étape par étape
Detailed breakdown of every message exchange, query parameter, and HTTP payload
Construct JWT Assertion
The client constructs a JSON payload containing standard claims: iss (client ID or service account), sub (subject), aud (token endpoint URL), exp (expiration time within minutes), and a unique jti identifier.
{
"iss": "service-account@project.iam.example.com",
"sub": "service-account@project.iam.example.com",
"aud": "https://auth.example.com/oauth/token",
"exp": 1740003600,
"nbf": 1740000000,
"jti": "d04b3a24-7389-4b68-b7d6-3e05a8b79b94"
}Cryptographic Signature
The client signs the JWT header and payload using its private asymmetric key (e.g. RS256, ES256, or EdDSA).
Exchange Assertion for Access Token
The client POSTs the signed assertion to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer.
POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNl...Validate Signature and Claims
The authorization server looks up the client registered public key, validates the digital signature, checks that the assertion has not expired, and ensures jti has not been replayed.
Issue Access Token
The authorization server returns an access token scoped to the client authorization.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token": "eyJhbGciOiJSUzI1NiIs...",
"token_type": "Bearer",
"expires_in": 3600
}API Call
The client uses the access token to authenticate requests to protected APIs.
GET /api/v1/cloud/resources HTTP/1.1
Host: api.cloud.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...Considérations de sécurité
Critical safeguards, threat mitigations, and implementation best practices
Short-Lived Assertions
The JWT assertion lifetime (exp - iat) must be very short, typically no longer than 5 minutes, to mitigate replay risks.
Enforce Replay Cache with jti
The authorization server should track and reject reuse of the jti (JWT ID) claim within the validity window to prevent replay attacks.
Private Key Protection
Private keys must be stored in Hardware Security Modules (HSMs) or cloud KMS services. Only publish public keys via JWKS.
Spécifications & Standards
Official IETF RFCs and OpenID Foundation standards defining this flow
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
Defines the assertion grant type and client authentication parameters using JWTs.
JSON Web Token (JWT)
Defines the core JSON Web Token format and claims semantics.
Other OAuth 2.0 Grant Types
Compare with other authentication and authorization flows