JSON Web Tokens
Fleeting- External reference: https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5
- External reference: https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3
- External reference: https://datatracker.ietf.org/doc/html/rfc7519
- External reference: https://datatracker.ietf.org/doc/html/rfc7519#section-1
- External reference: https://datatracker.ietf.org/doc/html/rfc7519#section-4.1
- External reference: https://jwt.io/introduction
The suggested pronunciation of JWT is the same as the English word “jot”.
- “iss” (Issuer) Claim
- “sub” (Subject) Claim
- “aud” (Audience) Claim
- “exp” (Expiration Time) Claim
- “nbf” (Not Before) Claim
- “iat” (Issued At) Claim
- “jti” (JWT ID) Claim
JSON Web Token (JWT, RFC 7519) is a way to encode claims in a JSON document that is then signed
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
JSON Web Token (JWT) is a compact claims representation format
This information can be verified and trusted because it is digitally signed
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties
JSON Web Token (JWT)
A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted.
JWT Claims Set A JSON object that contains the claims conveyed by the JWT.
Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.
Nested JWT A JWT in which nested signing and/or encryption are employed. In Nested JWTs, a JWT is used as the payload or plaintext value of an enclosing JWS or JWE structure, respectively.
JWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure.
This JSON object is the JWT Claims Set
The contents of the JOSE Header describe the cryptographic operations applied to the JWT Claims Set.
A JWT is represented as a sequence of URL-safe parts separated by period (’.’) characters. Each part contains a base64url-encoded value. The number of parts in the JWT is dependent upon the representation of the resulting JWS using the JWS Compact Serialization or JWE using the JWE Compact Serialization.
The following example JOSE Header declares that the encoded object is a JWT, and the JWT is a JWS that is MACed using the HMAC SHA-256 algorithm:
{“typ”:“JWT”, “alg”:“HS256”}
The set of claims that a JWT must contain to be considered valid is context dependent and is outside the scope of this specification.
in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.
three classes of JWT Claim Names: Registered Claim Names, Public Claim Names, and Private Claim Names.
None of the claims defined below are intended to be mandatory to use or implement in all cases, but rather they provide a starting point for a set of useful, interoperable claims.
All the names are short because a core goal of JWTs is for the representation to be compact.
The “iss” (issuer) claim identifies the principal that issued the JWT.
The “sub” (subject) claim identifies the principal that is the subject of the JWT.
The “aud” (audience) claim identifies the recipients that the JWT is intended for.
If the principal processing the claim does not identify itself with a value in the “aud” claim when this claim is present, then the JWT MUST be rejected.
The “exp” (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.
In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned
Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following:
Authorization: Bearer <token>
If the token is sent in the Authorization header, Cross-Origin Resource Sharing (CORS) won’t be an issue as it doesn’t use cookies.
benefits of JSON Web Tokens (JWT) when compared to Simple Web Tokens (SWT) and Security Assertion Markup Language Tokens (SAML)
Signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON.
As JSON is less verbose than XML, when it is encoded its size is also smaller, making JWT more compact than SAML
SWT can only be symmetrically signed by a shared secret
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object
it is digitally signed
can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
JWTs can be encrypted
JSON Web Tokens consist of three parts separated by dots (.), which are:
Header Payload Signature
JWT typically looks like the following. xxxxx.yyyyy.zzzzz
header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA. For example: { “alg”: “HS256”, “typ”: “JWT” }
this JSON is Base64Url encoded to form the first part of the JWT.
second part of the token is the payload, which contains the claims
claim names are only three characters long as JWT is meant to be compact
example payload could be: { “sub”: “1234567890”, “name”: “John Doe”, “admin”: true }
payload is then Base64Url encoded to form the second part of the JSON Web Token
The “aud” (audience) claim identifies the recipients that the JWT is intended for
“aud” value is an array of case-sensitive strings, each containing a StringOrURI value
— https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3
JWT claim
not before claim
4.1.5. “nbf” (Not Before) Claim
The “nbf” (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. The processing of the “nbf” claim requires that the current date/time MUST be after or equal to the not-before date/time listed in the “nbf” claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
— https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5
authorized party claim
azp Claim
unsecured jwt
Unsecured JWT is a JWS using the “alg” Header Parameter value “none”
JWT is a JWS or JWE
whether the JWT is a JWS or JWE
Notes linking here
- According to OAuth (blog)
- audience claim
- audience claim
- claims-based identity
- cross jwt confusion
- Footnotes
- goa
- how do I create an OAuth 2.0/OIDC resource server? (blog)
- ID Token validation rules
- ID Tokens vs Access Tokens
- Identity Token
- JSON Web Signature
- JSON Web Token Best Current Practices
- JWT Access Tokens profile for OAuth 2.0
- JWT Access Tokens profile for OAuth 2.0 may be different from implementations
- jwt cannot be used on blockchain
- keycloak provide many user related information in the access token by default.
- make sense of keycloak, openid connect, oauth 2.0, jwt, jws (blog)
- My opinion (blog)
- oauth - what’s the meaning of the “gty” claim in a jwt token?
- OAuth 2.0
- oauth 2.0 client
- OAuth 2.0 Token Introspection
- OpenID Connect
- OpenID Connect nonce vs JWT ID jti
- playing with auth0 for the first time
- RAS Syndrome - Sketchplanations
- Securing Applications and Services Guide
- self-encoded access tokens
- should I say JWT or JWT token, or JWS token or…? (blog)
- some uses of JWT token that I found interesting to spot
- three worlds analogy
- using a bearer token encoded in JWT format? (blog)
- using id token as access token?
- what should I put into those scopes and access tokens claims? (blog)