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

  • “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

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

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

“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

unsecured jwt

Unsecured JWT is a JWS using the “alg” Header Parameter value “none”

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

JWT is a JWS or JWE

whether the JWT is a JWS or JWE

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

Notes linking here