Konubinix' opinionated web of thoughts

JSON Web Tokens

fleeting

The suggested pronunciation of JWT is the same as the English word “jot”.

https://datatracker.ietf.org/doc/html/rfc7519#section-1

JSON Web Token (JWT, RFC 7519) is a way to encode claims in a JSON document that is then signed

https://oauth.net/2/jwt/

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.

https://datatracker.ietf.org/doc/html/rfc7519

JSON Web Token (JWT) is a compact claims representation format

https://datatracker.ietf.org/doc/html/rfc7519

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.

https://datatracker.ietf.org/doc/html/rfc7519#section-1

This information can be verified and trusted because it is digitally signed

https://jwt.io/introduction

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties

https://datatracker.ietf.org/doc/html/rfc7519

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.

https://datatracker.ietf.org/doc/html/rfc7519

JWT Claims Set A JSON object that contains the claims conveyed by the JWT.

https://datatracker.ietf.org/doc/html/rfc7519

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.

https://datatracker.ietf.org/doc/html/rfc7519

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.

https://datatracker.ietf.org/doc/html/rfc7519

JWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure.

https://datatracker.ietf.org/doc/html/rfc7519

This JSON object is the JWT Claims Set

https://datatracker.ietf.org/doc/html/rfc7519

The contents of the JOSE Header describe the cryptographic operations applied to the JWT Claims Set.

https://datatracker.ietf.org/doc/html/rfc7519

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.

https://datatracker.ietf.org/doc/html/rfc7519

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”}

https://datatracker.ietf.org/doc/html/rfc7519

The set of claims that a JWT must contain to be considered valid is context dependent and is outside the scope of this specification.

https://datatracker.ietf.org/doc/html/rfc7519

in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.

https://datatracker.ietf.org/doc/html/rfc7519

three classes of JWT Claim Names: Registered Claim Names, Public Claim Names, and Private Claim Names.

https://datatracker.ietf.org/doc/html/rfc7519

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.

https://datatracker.ietf.org/doc/html/rfc7519

All the names are short because a core goal of JWTs is for the representation to be compact.

https://datatracker.ietf.org/doc/html/rfc7519

The “iss” (issuer) claim identifies the principal that issued the JWT.

https://datatracker.ietf.org/doc/html/rfc7519

The “sub” (subject) claim identifies the principal that is the subject of the JWT.

https://datatracker.ietf.org/doc/html/rfc7519

The “aud” (audience) claim identifies the recipients that the JWT is intended for.

https://datatracker.ietf.org/doc/html/rfc7519

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.

https://datatracker.ietf.org/doc/html/rfc7519

The “exp” (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

https://datatracker.ietf.org/doc/html/rfc7519

In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned

https://jwt.io/introduction

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>

https://jwt.io/introduction

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.

https://jwt.io/introduction

https://jwt.io/introduction

benefits of JSON Web Tokens (JWT) when compared to Simple Web Tokens (SWT) and Security Assertion Markup Language Tokens (SAML)

https://jwt.io/introduction

Signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON.

https://jwt.io/introduction

As JSON is less verbose than XML, when it is encoded its size is also smaller, making JWT more compact than SAML

https://jwt.io/introduction

SWT can only be symmetrically signed by a shared secret

https://jwt.io/introduction

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

https://jwt.io/introduction

it is digitally signed

https://jwt.io/introduction

can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

https://jwt.io/introduction

JWTs can be encrypted

https://jwt.io/introduction

JSON Web Tokens consist of three parts separated by dots (.), which are:

Header Payload Signature

https://jwt.io/introduction

JWT typically looks like the following. xxxxx.yyyyy.zzzzz

https://jwt.io/introduction

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” }

https://jwt.io/introduction

this JSON is Base64Url encoded to form the first part of the JWT.

https://jwt.io/introduction

second part of the token is the payload, which contains the claims

https://jwt.io/introduction

claim names are only three characters long as JWT is meant to be compact

https://jwt.io/introduction

example payload could be: { “sub”: “1234567890”, “name”: “John Doe”, “admin”: true }

https://jwt.io/introduction

payload is then Base64Url encoded to form the second part of the JSON Web Token

https://jwt.io/introduction

The “aud” (audience) claim identifies the recipients that the JWT is intended for

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1

JWT claim

Notes linking here