Tokens & JWT · Brennenstuhl on Security

What is inside a JWT?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: A signed JWT is 3 base64url-encoded parts joined by dots: a header that names the algorithm, a payload of claims, and a signature over both. The payload is encoded, not encrypted, so anyone holding the token can read it; only a signature check with a key you trust tells you whether to believe it.

Key findings #

A JWT is a set of claims encoded as a JSON object inside a JWS or a JWE, so the same token format can be signed, encrypted, or both.

Source: RFC 7519, JSON Web Token (JWT), Section 2

Link to this finding Save as image (PNG, 1200 by 630 pixels)

The payload of a signed JWT is only base64url-encoded, so a token that carries privacy-sensitive claims needs encryption or must not reach parties who should not read it.

Source: RFC 7519, Section 12, Privacy Considerations

Link to this finding Save as image (PNG, 1200 by 630 pixels)

RFC 7519 registers 7 claim names, iss, sub, aud, exp, nbf, iat and jti, and none of them is mandatory in every case; each application profile decides which it requires.

Source: RFC 7519, Section 4.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

JWT libraries must let the caller specify the supported algorithms and must not use any other algorithm, which closes the door on tokens whose header was changed to “none”.

Source: RFC 8725, JSON Web Token Best Current Practices, Section 3.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Specifications
Study	Year	Sample	Method	Finding
RFC 7519: JSON Web Token (JWT)IETF	2015	n/a	Specification	Defines the JWT format, the registered claim names and the privacy considerations for claims.
RFC 7515: JSON Web Signature (JWS)IETF	2015	n/a	Specification	Defines the compact serialization: base64url header, payload and signature joined by dots.
RFC 8725: JSON Web Token Best Current PracticesIETF (BCP 225)	2020	n/a	Best current practice	Requires algorithm allowlists in libraries and audience, issuer and key validation in applications.

What to do #

For engineers #

Treat a decoded payload as untrusted input until the signature verifies. Pin the algorithms you accept instead of reading alg from the token, and resolve the key by kid only from a key set you trust, such as the issuer’s JWKS.
After the signature, check exp, nbf, iss and aud. RFC 8725 makes audience validation a must whenever one issuer serves several relying parties.
Keep secrets and personal data out of signed tokens. If a token has to carry them, use JWE or keep the data on the server and put a reference in the token.

For product and UX #

Tokens end up in logs, browser storage and support tickets. Anything in the payload should be safe to show to whoever might see it there.
Short token lifetimes are a product decision as much as a security one: they decide how often a session has to be refreshed.

Try it #

Decode a token in your browser

The example token below has 3 parts. Paste your own token into the decoder to split and decode it. Decoding happens only in your browser; nothing is sent anywhere, and the signature is not verified.

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjIwMjYtMTAifQ.eyJpc3MiOiJodHRwczovL2lkLmV4YW1wbGUuY29tIiwic3ViIjoidXNlci0xMjMiLCJhdWQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImV4cCI6MTc5MTkwMDAwMCwiaWF0IjoxNzkxODk2NDAwLCJqdGkiOiI3ZjNjOWEifQ.cGxhY2Vob2xkZXIgc2lnbmF0dXJlLCBub3QgdmFsaWQ

Header decodes to {"alg":"ES256","typ":"JWT","kid":"2026-10"}: an ECDSA P-256 signature, and the ID of the key that made it.
Payload decodes to {"iss":"https://id.example.com","sub":"user-123","aud":"https://api.example.com","exp":1791900000,"iat":1791896400,"jti":"7f3c9a"}: issued at 13:00 UTC on 13 October 2026, expiring 1 hour later.
Signature is a placeholder in this example. In a real token it is the ES256 signature over the encoded header and payload, checked with the issuer’s public key from its JWKS.

How the parts fit together #

The header and payload are JSON objects. Each is encoded with base64url, a URL-safe variant of base64 without padding, and the two results are joined with a dot. The signer signs that string with the algorithm named in the header and appends the base64url-encoded signature after a second dot. That is the JWS compact serialization from RFC 7515.

A verifier reverses the steps: split at the dots, decode the header, pick the key and algorithm it allows, and verify the signature over the first 2 parts exactly as received. Only then does it decode the payload and evaluate the claims. The essays on the purpose of JWT, JSON Web Algorithms and JWT versus OAuth 2.0 go deeper.

What is JWA? A Deep Dive into JSON Web Algorithms

Thu, 08 Jun 2023 00:00:00 +0200

Definition of JWA #

JSON Web Algorithms (JWA) is a specification providing a list of cryptographic algorithms. It’s an integral part of the JSON Object Signing and Encryption (JOSE) family of standards. JOSE includes, for example, JSON Web Tokens (JWT), JSON Web Signature (JWS), and JSON Web Encryption (JWE).

JWA provides definitions for several cryptographic algorithms. These algorithms enable various purposes.

In this guide, you’ll learn the following:

How to decode JWA short names
What JWAs there are
Why JWA matters for OpenID Connect

Anatomy of JSON Web Algorithms #

The JWA specification defines a unique name for every algorithm. These names are short strings encoding the particular algorithm family and hashing algorithm. Variants for SHA-256, SHA-384, and SHA-512 exist for most signing algorithms.

The most common algorithm names defined in the JWA specification include the following:

Algorithm Name	Algorithm Description
HS256	HMAC with SHA-256
RS256	RSA signature with SHA-256
ES256	ECDSA using P-256 and SHA-256
RSA-OAEP	RSAES OAEP using default parameters
A128KW	AES key wrap with 128-bit key

RFC 7518 defines the fundamental base JSON Web Algorithms. The JOSE IANA registry provides a complete list of supported algorithms. These unique references allow receivers to identify the correct cryptographical procedure. They are part of the JOSE header.

Different Types of JSON Web Algorithms #

The JWA specification defines many cryptographic algorithms powering various use cases, including:

Signing with JSON Web Signature (JWS) ensures a token’s integrity during transit.
Encryption with JSON Web Encryption (JWE) to safeguard the confidentiality of token payload.
Distribution with JSON Web Keys (JWK) to enable distributed JWT validation.

All JSON Web Algorithms are either symmetric or asymmetric.

Understanding the Symmetric Key Algorithms #

Hash-Based Message Authentication Codes (HMAC) are a popular algorithm class for signed JWTs. HMACs like HS256 provide a way of signing messages using a shared key. They belong to the family of symmetric cryptographic algorithms.

Symmetric algorithms need all involved parties to know the same key. They are helpful when all clients can guarantee the secrecy of the shared key. Their permissive nature allows all key possessors to create and verify JWTs. HMACs are best used in setups with one central issuer/ verifier.

Delving into Asymmetric Key Algorithms #

JWA specifies two asymmetric encryption and digital signature algorithm families – RSA and ECDSA. Public-private key pairs form the foundation of asymmetric algorithms. They enable decoupling verification or decryption of a token from being able to forge a new one. This is essential for distributed token validation scenarios. It allows decentralized authorization decision-making in OAuth 2.0 and OpenID Connect (OIDC).

Practical Applications of JWA #

A widespread use case is decentralized token signature verification for asymmetrically signed JWT. It’s a key enabler for OpenID Connect.

At the forefront of this practical application is a central authorization server. This token issuer holds a private signing key and exposes its public key material. Clients in need to verify tokens fetch the public keys from the well-known JWK endpoint. Based on cryptographic meta information carried in the JWT header, clients identify the matching key and JWA. This way, relying parties can verify a token’s integrity without the need for centralized introspection.

Conclusion #

JWA is part of the JSON Web Token (JWT) suite of technologies. It’s a collection of cryptographic algorithms. Being a vital ingredient of every JWT, JWA powers the entire JOSE toolbox. These JOSE technologies build secure systems that can interoperate easily. OpenID Connect is a famous example of such a framework.

Please note that each JSON Web Algorithm has its security implications. Appropriate use cases depend on the specifics of the implementation. It is paramount to choose algorithms that best meet your specific security requirements.

Mastering JWKS: JSON Web Key Sets Explained

Fri, 02 Jun 2023 00:00:00 +0200

TL;DR #

JWKS (JSON Web Key Set) is a tool for standardizing the representation and management of cryptographic keys via a JSON object.
The technology, defined in RFC 7517, enables client-local JWT (JSON Web Tokens) verification and is integral for decentralized authentication protocols such as OpenID Connect and OAuth2.
Implementing JWKS simplifies key management, eases key rotation, and secures key distribution across multiple servers.

Technical Specifications of JWK and JWKS #

JWKS is an acronym for JSON Web Key Set. It is a collection of JSON Web Keys (JWKs) used to verify JSON Web Tokens (JWTs). Both constructs are defined in RFC 7517, yet another integral member of the famous JOSE standards family. JWK Sets provide a standardized way and format for servers to obtain the public keys required to verify asymmetrically signed JWTs locally.

What is JSON Web Key (JWK)? #

A JWK is a JSON object data structure that represents a cryptographic key. It contains the key type, key operations, algorithm, and all relevant material to reconstruct the signature verification key. All officially supported JSON Web Algorithms (JWA) are defined in RFC 7518.

The JSON data structure of the JWK format allows for easy, web-native exchange of public keys. The representation of an Elliptic Curve signature key of curve P-256 could look like this:

{
 "kty": "EC",
 "use": "sig",
 "crv": "P-256",
 "kid": "01H1SG7BX197N040C0MHTDV1HR",
 "x": "SEfcECpwqQg-vZ6Lv99RyV0Qkatngz1RV25nI5SOrPg",
 "y": "YU2PRA6pXZ62OW_XuzjJqplqmBUtBwT2pKUZUVxUYfc",
 "alg": "ES256"
}

What is JSON Web Key Set (JWKS)? #

A JWKS is a JSON object that represents a set of JWKs. It must contain a “keys” member and an array of JWKs. JSON Web Key Sets enable identity providers to support and expose more than one public key under a well-known resource. The following example JWK Set format contains two public cryptographic keys – one using an Elliptic Curve (EC) algorithm and a second one using an RSA algorithm:

{"keys":
 [{
 "kty": "EC",
 "use": "sig",
 "crv": "P-256",
 "kid": "01H1SG7BX197N040C0MHTDV1HR",
 "x": "SEfcECpwqQg-vZ6Lv99RyV0Qkatngz1RV25nI5SOrPg",
 "y": "YU2PRA6pXZ62OW_XuzjJqplqmBUtBwT2pKUZUVxUYfc",
 "alg": "ES256"
 }, {
 "kty":"RSA",
 "n": "1qrQCTst3RF04aMC9Ye_kGbsE0sftL4FOtB_WrzBDOFdrfVwLfflQuPX5kJ-0iYv9r2mjD5YIDy8b-iJKwevb69ISeoOrmL3tj6MStJesbbRRLVyFIm_6L7alHhZVyqHQtMKX7IaNndrfebnLReGntuNk76XCFxBBnRaIzAWnzr3WN4UPBt84A0KF74pei17dlqHZJ2HB2CsYbE9Ort8m7Vf6hwxYzFtCvMCnZil0fCtk2OQ73l6egcvYO65DkAJibFsC9xAgZaF-9GYRlSjMPd0SMQ8yU9i3W7beT00Xw6C0FYA9JAYaGaOvbT87l_6ZkAksOMuvIPD_jNVfTCPLQ",
 "e":"AQAB",
 "alg":"RS256",
 "kid":"01H1SGVCX7GKBGE2J2QMQREAGN"
 }]
}

Locate JSON Web Key Sets #

Many modern identity providers like Google expose their JWK Sets via the jwks_uri attribute within the well-known discovery endpoint of OpenID Connect (OIDC) located at https://{identity-provider}/.well-known/openid-configuration which often points to https://{identity-provider}/.well-known/jwks.json or a similar resource.

Benefits of Using JWKS #

Easy Management of Keys with JWK Sets #

One of the main benefits of using JWKs is that they provide an easy way to manage and distribute keys across multiple servers or locations. Instead of hardcoding public keys into application code, token issuers (authorization servers) only need to provide their clients with an URL for their JSON Web Key Set.

Any application that needs access to the keys can retrieve them from that remote location. This eliminates the need for manual key distribution, resolves, and ensures all applications use the same set of keys. This makes it easier to manage multiple keys and rotate them when necessary.

Simplified Key Rotation Process Using JWKs #

Rotating keys is essential for maintaining security in any system that uses cryptography. However, manually replacing these keys can take time and effort. JWKS can simplify this process by automating key rotation.

As JWKs decouple the authorization server from relying party applications, token issuers can generate new asymmetric key pairs whenever necessary. Setting up regular intervals for key rotation, publishing the new public key material, and using the latest private key automatically after some grace period, can ensure that the amount of keys signed with a particular key has a natural upper limit.

Compatibility with Various Protocols and Applications #

Finally, the JSON Web Key Set standard is compatible with various protocols and applications. This means it can enable local token validation in the context of web applications, APIs, mobile apps, and more. Popular authentication protocols such as OAuth 2.0 and OpenID Connect support JSON Web Key Set.

Best Practices & Security Considerations #

Dealing with cryptographic and primarily private keys is a highly sensitive undertaking. The security issues relevant to any cryptographic application must also be considered when dealing with JSON Web Token (JWT) and JSON Web Signature (JWS). It is essential to implement JSON Web Key Set (JWKS) correctly to ensure the security and integrity of the entire infrastructure. Here are some best practices for implementing JWKS.

Use Transport Layer Security #

Serving a JSON Web Key over HTTP poses significant security risks as it can be intercepted or modified in transit. Therefore, it is crucial to use HTTPS also when serving JWKS. HTTPS ensures that all communication between the client and server is encrypted, preventing unauthorized access or in-transit modification.

Make sure JWKS is correct and current #

The entire system’s security relies on having up-to-date and accurate JWKS. If any cryptographic keys in the set expire or become invalid, it could result in rejected tokens or, worse yet, accepted but fraudulent tokens being used throughout the system. It’s essential to have processes in place to monitor and update JSON Web Keys regularly. This includes rotating keys, removing EOL keys, and adding new keys as necessary. Cryptographic key management should be automated to ensure that all cryptographic keys are always up-to-date. Symmetric keys must not be exposed!

Validate the signatures of incoming JWTs using JWKs #

One of the primary purposes of implementing JWKS is to verify the authenticity of incoming JWTs – be it access token or ID token. To do this, all applications that perform authorization decisions based on JSON Web Token, should fetch the entire JSON Web Key Set per the corresponding cache-control headers.

Validating a JWT starts with fetching the kid (key ID) parameter from its header. This key identifier specifies which cryptographic key in the JWKS was used by the authorization server to sign the token. The identified key can then be used to verify the signature by comparing it against the one included in the token’s signature.

If the signature is valid, the token was issued by a trusted party and can be processed accordingly. An invalid token must be rejected immediately.

Consider rotating your JWKS keys periodically #

Rotating JSON Web Keys periodically is an essential best practice for maintaining a proper security posture. Doing so reduces the risk of compromised keys being used maliciously throughout the system. Rotating keys effectively requires creating a new set before retiring any old ones. This will ensure no gaps in coverage during the transition period.

Conclusion: The Importance of Using JSON Web Key Sets #

Implementing JSON Web Key Sets (JWKS) is crucial for organizations that leverage decentralized authentication protocols like OpenID Connect or authorization delegation protocols like plain OAuth2. Truly benefiting from public-key cryptography requires client applications to verify issued tokens locally, without indispensable synchronous HTTP requests.

Using a data interchange format like JSON Web Key (JWK), which is based on JavaScript Object Notation (JSON), and hosting the cryptographic keys on publicly accessible, standardized discovery endpoints allows maintaining decoupled service architectures while shifting effort to the client-side following a pull principle.

JSON Web Encryption: Exploring JWE Token

Mon, 29 May 2023 00:00:00 +0200

TL;DR #

JSON Web Encryption (JWE) is a standard for securing data transmission between parties, providing confidentiality, integrity, and authentication. It uses encryption to protect the payload of a JSON Web Token (JWT) and supports both symmetric and asymmetric encryption techniques. It also allows creating nested JWTs, combining the advantages of JWE and JSON Web Signature (JWS).
A JWE token consists of five parts: the Protected Header, the Content Encryption Key, the Initialization Vector, the Ciphertext, and the Authentication Tag. It supports various encryption algorithms like RSA-OAEP, AES-GCM, and ECDH-ES and requires using authenticated encryption to ensure the token’s integrity and confidentiality.
Modern authentication and authorization frameworks like OAuth2 and OpenID Connect (OIDC) use JWE tokens as bearer tokens. Proper key management is crucial to maintain the security guarantees of JWE.

JSON Web Encryption (JWE) Token: A Comprehensive Guide #

JWE is a widely-used standard for securing data transmission between parties. The industry standard describes a JSON Web Token (JWT) type that uses encryption to protect its payload. It provides confidentiality by encrypting the transmitted data, ensuring only authorized parties can access and read it.

In addition to providing confidentiality, JWE tokens offer integrity protection through message authentication codes (MACs). These codes ensure the receiver can detect tampering with the encrypted payload. Depending on the key management mode, it can also provide authentication.

JWE is relevant for modern AAA concepts in distributed, stateless environments as it enables an exchange of sensitive information statelessly.

The Structure of an Encrypted JWT #

The JWE standard (RFC 7516) is the go-to solution for developers who need to transmit JSON objects over the internet securely. JWE is a standard that defines how to encrypt and decrypt data in JSON format using various algorithms. In this section, I will discuss some of the core concepts of JWE tokens.

A typical, compact serialized, encrypted JWT is a dot (.) separated string that contains five parts:

The JWE Protected Header is a base64url-encoded string representing the token metadata. It describes the JWE, how it was encrypted, and the media type of the encrypted payload. Protected JWE headers can’t be encrypted as they carry all information necessary for decryption.
The JWE Encrypted Key (CEK) is another base64url-encoded string representing the encrypted, symmetric key used to encrypt the payload.
The JWE Initialization Vector (IV) is a base64-encoded unique, random value string used when encrypting the plaintext and helps prevent attackers from exploiting patterns in plaintext or ciphertext.
The JWE Ciphertext, the actual encrypted payload, also base64url-encoded, which was encrypted using the CEK, along with the IV and the additional authenticated data (AAD).
The JWE Authentication Tag (MAC) results from performing authenticated encryption and allows a verifier to prove the integrity of the ciphertext and the AAD (the encoded protected header when using compact serialization). It ensures integrity during decryption.

Support for Symmetric and Asymmetric Encryption Algorithms #

Encrypted JWTs support asymmetric and symmetric encryption techniques to provide end-to-end security for the transmitted data. Symmetric encryption algorithms use the same key for encryption and decryption, while asymmetric algorithms use a pair of keys.

The sender encrypts the plaintext payload using a randomly generated symmetric CEK, then encrypts the key using the recipient’s public key or a shared secret key (a long-lived key encryption key). The recipient can then decrypt the encrypted key using their private secret key and use it to decrypt the payload.

As they are self-contained and carry their corresponding symmetric key (CEK), encrypted JWTs also support hybrid encryption, which allows combining the performance of symmetric encryption with the assurances of public-key cryptography. This flexibility lets developers choose between different encryption algorithms based on their needs.

Nested JWTs #

Another exciting feature of JWE is the ability to create nested JWTs. As the JWE standard allows arbitrary data to be packaged into the payload, it also allows nesting a signed JWT (JWS) inside an encrypted JWT (JWE). Wrapping a JWS into a JWE can be helpful when dealing with asymmetrically encrypted JWE, as these alone do not allow to verify that the JWT was produced by a specific token issuer, merely that someone who possessed the issuer’s public key forged the token. Nested JWTs combine the advantages of JWE and JWS. Symmetrically encrypted JWEs provide all the above security properties without creating nested tokens.

Working with Different JWE Algorithms #

The JSON Web Algorithms (JWA) standard registers all cryptographic algorithms supported by the JWT ecosystem in RFC 7518. The most commonly recommended option for asymmetric key encryption is ECDH-ES, while AES-GCM (with key wrapping) is the recommended alternative for symmetric encryption setups.

JWE with AES Algorithms #

AES (Advanced Encryption Standard) algorithm is still the de-facto standard of a symmetric algorithm that can be used with JWE. It involves using the same secret key to encrypt and decrypt data. The JWE token can be encrypted using AES-GCM (Galois/Counter Mode), which provides authenticated encryption with associated data (AEAD). AES128 should be fine for “short-lived” tokens (<34 million years).

JWE with RSA Algorithms #

RSA (Rivest-Shamir-Adleman) is an example of an asymmetric encryption algorithm supported by JWE. It involves generating a key pair where the public key encrypts data while the private key allows to decrypt it. Commonly used in JWE token contexts is RSA-OAEP (Optimal Asymmetric Encryption Padding).

JWE with Elliptic Curve Algorithms #

Elliptic Curve Cryptography (ECC) is another example of an asymmetric cryptography system supported by JWE. It involves generating a key pair based on elliptic curves rather than prime numbers. The JWE token can be encrypted using ECDH-ES (Elliptic Curve Diffie-Hellman Key Agreement with Elliptic Curve Cryptography) or ECDH-ES+A128KW (ECDH-ES with AES key wrap).

Authenticated Encryption Algorithms #

JWE requires using authenticated encryption (AE) to ensure that the token is encrypted and integrity protected, supporting multiple AE algorithms. Two distinct classes exist, authenticated encryption with AES/CBC/HMAC/SHA and AES/GCM. The latter also supports Authenticated Encryption with Associated Data (AEAD), which provides confidentiality, integrity, and authenticity of the encrypted message and additional authenticated data. It ensures that the message has not been tampered with during transmission.

JWE Token Generation Process #

Encryption Algorithm: Choosing the Right One for Your Needs #

Choosing a suitable algorithm is crucial when generating a JWE token. There are several options available, including AES-GCM, AES-CBC-HMAC-SHA2, and RSA-OAEP. Each algorithm has strengths and weaknesses, so choosing one that aligns with specific needs and requirements is essential.

Generating Keys: Private Key vs Secret Key #

The process of generating keys for JWE tokens differs depending on the form of encryption. Applying symmetric encryption requires generating a random secret key that both the sender and receiver can use to encrypt and decrypt data. Asymmetric encryption involves creating a public-private key pair.

Complete JOSE Header #

The process of generating a JWE token is complex and involves several steps. The first step is the creation of a complete JOSE header that contains information about the encryption algorithm, key management algorithm, key ID (kid), and other critical details. This header is essential because it provides the foundation for creating a secure and valid JWE token.

Encryption & Serialization: Creating Valid JWE Tokens #

Once a suitable encryption algorithm is chosen and keys generated, it’s time to encrypt the payload involving an appropriate initialization vector (IV). After successfully calculating the ciphertext and the corresponding authentication tag, all individual parts are appropriately encoded and joined into their compact serialization format. As JWE deals with various cryptographic algorithms, is somewhat complex, and can become confusing, I recommend leveraging standard libraries to create encrypted and properly serialized JWT.

JWE Token Decryption Process #

Decoding the JWE Compact Serialization #

Decrypting a JWE token starts with decoding the JWE compact serialization. The JWE compact serialization is a string comprising five parts separated by dots: the JWE header, the encrypted key, the initialization vector, the JWE ciphertext, and the authentication tag. It is the most commonly used type compared to the less popular JWE JSON serialization.

The protected header contains information about the encryption and key management algorithms used to encrypt the payload. This information is required to decrypt the token. Once being (base64url) decoded, these claims are accessible for introspection.

Key Decryption #

Access to the private secret key initially used to encrypt is required to decrypt the JWE token. The decryption algorithm referenced in the JOSE header defines the cryptographic procedure for the CEK. Only after decryption can it unlock the actual payload. In the case of public key cryptography, the associated private key must be available. Single-key encryption requires the corresponding secret shared between both parties to be present.

Payload Decryption #

The IV value initializes the cipher instance with an appropriate mode like CBC, GCM, etc. The previously obtained JWE encrypted key (CEK) can decrypt the JWE ciphertext value, yielding a plain text (often a JSON object) after successful decryption. The integrity of the ciphertext and its additional authenticated data (AAD), in this case, the JWE header elements, is verified using the authentication tag value provided in the last part of the serialized JWE object.

Security Considerations #

Authentication Tag and Additional Authenticated Data #

One key feature that makes JWE tokens secure is using an authentication tag and additional authenticated data (AAD). The authentication tag is a small piece of data at the end of the encrypted JWT, which allows recipients to verify that the message has not been tampered with during transmission. AAD provides an extra layer of security by enabling the sender to include additional data in the encryption process that the recipient will verify.

However, not all JWE tokens have an authentication tag or AAD. There are JWA encryption algorithms that do not use an authentication tag, in which case the value is supposed to be an empty octet sequence.

Leaky Headers #

Another potential security concern when using JWE tokens is custom header elements. JWT headers include public claims by design that are integrity protected at max. Using customer header claims means they can potentially leak sensitive information if mismanaged. It’s crucial to handle custom header claims carefully and only include necessary information. If confidentiality is needed, custom fields belong in the payload. If there is a need for public hints, the header metadata is just fine.

Key Management and Token Expiry #

Proper key management is essential for maintaining the security of JWE tokens. Identity providers must store the long-lived key management keys securely and rotate them regularly to prevent unauthorized access, as compromise might result in disclosing all contents protected with that key.

Similarly, successful attacks on the CEK will strip all confidentiality properties from the corresponding token. Implementing token expiry to limit the amount of time token usage before it becomes invalid is necessary for all everyday use cases.

Weak algorithms #

The JWE specification includes a limited range of supported encryption algorithms. And also, the officially supported ones rarely convince security experts: The ECDH-ES algorithm allows an attacker to recover the private key if not adequately implemented. GCM is likely fragile, as Google researchers claim. And RSA encryption with PKCS1v1.5 padding is broken.

When leveraging JWE, I recommend supporting short notice and timely transitioning to alternative encryption algorithms.

Comparison of JWE and Other JSON Security Standards #

JWE vs JWT #

While both JWE and JWT are part of the JSON Object Signing and Encryption (JOSE) security framework, they serve different purposes. As mentioned, JWEs provide JSON data encryption, while unsecured JWTs (RFC 7519) provide no particular security properties. In identity and access management (IAM) scenarios where a client sends a token to a resource server as proof of identity, JSON Web Tokens commonly appear in their signed JWS form.

JWE vs JWS (JSON Web Signature) #

JWS is a JSON-based format for representing digital signatures (RFC 7515). JWS assures integrity and authentication, but it does not provide confidentiality. JWS tokens contain three elements: the JOSE header, payload, and signature. On the other hand, JSON Web Encryption (JWE) is a standard for encrypting JSON data. JWE tokens protect sensitive data by also providing confidentiality.

JWE vs JWK (JSON Web Key) #

JWK is another standard in the JOSE family (RFC 7517) that defines JSON format for cryptographic keys. A JWK Key Set (JWKS) can contain keys used for either encryption or signing, depending on their type. JWKs can be used with both JWS and JWE standards to provide cryptographic operations such as decryption or verification of digital signatures.

Practical Applications of JWE Tokens #

The nature of JWE tokens makes them ideal for enabling stateless information exchange in modern AAA processes or exotic one-time-token (OTT) scenarios. In this section, I will discuss some practical applications of JWEs.

Bearer Token: A Powerful Authentication and Authorization Tool #

JWEs often appear as bearer tokens to authenticate and authorize access to protected resources. Bearer tokens are powerful tools because they allow users to access resources without repeatedly providing credentials. Instead, the bearer token serves as proof of identity and authorization.

JWE in OAuth2 and OIDC #

OAuth2 and OpenID Connect (OIDC) are widely used authentication/ authorization protocols, often used for securing web APIs. They allow users to grant access to their resources without sharing their credentials with third-party applications. These protocols can use JWE Tokens to provide an additional layer of security by encrypting the access token. Enforcing clients to treat them as genuinely opaque tokens allows the token issuer (authorization server) to transport sensitive information like PII statelessly. At the same time, it also ensures that even if an attacker intercepts the token, they cannot read its contents without the decryption key.

JWE for Data at Rest #

Data at rest refers to data stored on disk or other storage media. This data is vulnerable to attacks if it is not adequately secured. Although not common, JWE tokens can encrypt sensitive data before storing it on disk, ensuring that even if an attacker gains access to the storage media, they cannot read its contents without the decryption key.

Conclusion #

JSON Web Encryption (JWE) is a powerful tool for ensuring the confidentiality and security of data transmissions. JWE tokens carry an encrypted payload between multiple parties. The secured data can only be read with the proper decryption key, even if intercepted. Authenticated encryption ensures that sensitive information remains confidential and tamper-proof, providing both senders and receivers peace of mind.

The use cases for JWE tokens are varied and versatile. Use JWE in situations where confidential data exchange is necessary. When used as a bearer token within modern authorization and authentication frameworks like OpenID Connect (OIDC), JWE tokens transport sensitive information often as access tokens.

Frequently Asked Questions (FAQs) #

What is the purpose of JWE? – JWE tokens securely transmit data between parties in a JSON format. They provide confidentiality, integrity, and authenticity to the transmitted data.
How does JWE differ from JWT? JWE focuses on encrypting the payload, while plain JWT provides no additional security properties.
What are standard encryption algorithms used in JWE? Some common encryption algorithms include RSA-OAEP, AES-GCM, and ECDH-ES.
Is it safe to use JWE tokens for sensitive data? Yes, as long as proper security measures are taken, such as using robust encryption algorithms and protecting the encryption and decryption keys.
Can JWE be used with other JSON security standards? JWE can be combined with other JOSE, such as JWS, to support even more complex scenarios with nested JWTs.

JWT vs OAuth 2.0: Understanding the Key Differences

Wed, 24 May 2023 00:00:00 +0200

TL;DR #

OAuth 2.0 is an open standard that describes an authorization framework. It allows a third-party application to access a user’s resources without user credentials.
JWT (JSON Web Tokens) is a standard that describes a JSON-based token format used to securely transfer information between two parties across an insecure environment.
Combining OAuth 2.0 and JWT: JWT can be integral to the OAuth 2.0 framework . In fact, JWT has often been used as the bearer token in OAuth 2.0 implementations.
OpenID Connect (OIDC): Modern authentication and authorization mechanisms leverage the OAuth 2.0 fundamentals with JWT tokens by following OpenID Connect protocols.

Introduction to JWT vs OAuth 2.0 #

Most people encounter OAuth2 and JSON Web Tokens (JWT) in the context of authentication and authorization for web applications. While both concepts nowadays get used together, comparing OAuth2 vs JWT is like comparing apples to kittens.

10 years after the last update to the OAuth 2.0 Authorization Framework standard (RFC 6749) and over eight years after JSON Web Tokens got unleashed to the world, there is still a lot of confusion around these two widespread open standards among software engineers and security engineering novices. In this article, I will explain why comparisons like “JWT vs OAuth 2.0” or questions like “OAuth vs JWT which is best” make little sense.

What is OAuth2? #

OAuth2 is an open standard describing an authorization framework that allows a third-party application to access a user’s resources without giving them the user’s credentials. The keywords here are authorization protocol and delegated access. It does this by providing the concept of access tokens that can be used by a client application to access protected resources (like an API) exposed by a resource server on behalf of the resource owner (a user). These opaque tokens are issued by an authorization server after the user grants permission to the third-party application.

What is JWT? #

On the other hand, the JWT standards describe a JSON-based token format and how it can securely transfer information between two parties across an insecure environment (like HTTP or HTTPS). Their multipart JSON format structure allows JWTs to carry custom claims as payloads and additional cryptographic accessories. They are self-contained and usually occur in their JSON Web Signature form, signed with a secret key or public/private key pair. I wrote about “The Purpose of JWT” a few years ago.

When to Use OAuth 2.0 vs When to Use JWT #

Use OAuth 2.0 with HTTPS when authorizing third-party access.

OAuth 2.0 is a protocol that allows users to grant limited access to resources on one site, such as Facebook, to another location or application, without sharing their credentials or giving them complete control over their account. It provides a secure way of authorizing third-party access to your resources by using access tokens in the form of bearer tokens.

After the resource owner grants permission for the client application to access their resources using OAuth2, the responsible authorization server issues the proof of authentication. These tokens are then sent with each request made by the client application to the resource server, verifying them and granting or denying access based on the services requested and claims provided.

Bearer tokens are a type of access token that can be used by arbitrary parties in possession of them to gain access to the protected resources they represent. They do not contain any cryptographic proof of authenticity other than possession itself, so they must be kept secret and transmitted securely.

OAuth 2.0 is an excellent choice when you must permit controlled interaction between third-party applications or services managed by different entities or individuals with your system without compromising sensitive information or risking unauthorized access. This is possible through various security mechanisms such as opaque tokens, bearer tokens, identity servers, and refresh tokens.

Use JWT when securely transmitting information between parties in a stateless form.

JSON Web Tokens are basically use cases agnostic and can generally be used for securely transmitting information between parties in stateless form. It provides a simple way of representing claims (e.g., user identity, permissions) as JSON objects that can be signed and/or encrypted using industry-standard algorithms.

JWTs are often used for transporting proof of authenticity across multiple domains or applications without storing session data on the server side, significantly contributing to performance. They are also helpful for implementing single sign-on (SSO) functionality, where a user logs in once and gains access to multiple applications or services without claiming their identity again. And this is basically where OAuth 2.0 and JWT touch on each other.

Combining OAuth 2.0 and JWT: How to Use Them Together #

The apparent overlap between JWT and OAuth 2.0 springs from a misunderstanding of their distinct roles in digital communications. JWT can be an integral part of the OAuth 2.0 framework. In fact, JWT often serves as the bearer token in OAuth 2.0 implementations, becoming the vehicle by which authorization information is conveyed.

JWT as Bearer Token #

JWTs can be used by an app as OAuth2 bearer tokens to enable stateless authentication and local authorization by a resource server to grant access to a protected resource.

Bearer tokens are a type of token that is widely used in authentication protocols like OAuth 2.0. They are used to grant access to protected resources, and they come in two types: access tokens and refresh tokens. While access tokens are short-lived, refresh tokens can be renewed, allowing users to maintain their session for an extended period.

JWTs are often used in combination with OAuth 2.0 as a means of transmitting state and user data (claims) between the authorization server and the resource server. They can also be used for client-side authentication, where a JWT is issued by an identity provider after successful login and then sent to the client application, which uses it to authenticate itself on behalf of the actual user with other services.

Advantages of Using JWT with OAuth 2.0 #

One significant advantage of using JWT with OAuth 2.0 is eliminating the need for multiple tokens for different app purposes. One token can contain all the necessary information for authentication and authorization purposes.

Another benefit can be improved performance through stateless authentication. Since JWT tokens are self-contained and signed with a secret key or public/private key pair, there is less reliance on external servers for validation and introspection. JWT is very suitable for stateless applications as they relieve the server side from the need to store any particular session data between requests from the clients.

Instead, all necessary data is carried around within each JWT token itself, making it easy for clients and servers alike to verify its authenticity without looking up anything outside of it. This reduces the number of database lookups required during token verification, leading to faster response times, increased reliability due to fewer bottlenecks, and a potentially cleaner architecture.

Which Bearer Token Format is Right for You? #

Choosing the suitable OAuth 2.0 access token format can be a daunting task. Both stateful tokens and stateless JWT have their strengths and weaknesses. It ultimately depends on specific use cases, requirements, and infrastructural preconditions.

Modern authentication and authorization mechanisms leverage the OAuth 2.0 fundamentals together with JWT tokens by following OpenID Connect (OIDC) protocols, which is an extension on top of OAuth 2.0 that introduces the concept of an identity provider (aka identity server) and uses JWTs instead of opaque tokens.

JWT + OAuth2 = OpenID Connect (OIDC) #

Big tech organizations such as Google, Facebook, and Microsoft are OIDC power users:

Google Identity uses OIDC and its identity token to transport user details.
Facebook also uses OIDC with JWTs in its Graph API authentication mechanism.
Microsoft’s Azure Active Directory (AAD) also leverages the JWT token to implement OIDC.

Whether you choose classic OAuth 2.0 with opaque, non-JWT tokens, OAuth 2.0 with JWT bearer token, or OIDC, make sure you understand how these frameworks work under the hood, embrace their core concepts and get your implementation externally certified to ensure maximum security for your users’ data while also providing seamless access to your application’s features and resources. The better way, however, is to outsource the authentication to Google, Microsoft, Okta, or someone else and let them deal with all the nifty little details in these specifications.

Conclusion: Choosing Between JWT and OAuth2 #

Combining OAuth 2.0 and JWT can give you the best of both worlds. OpenID Connect is built on both open standards, embracing OAuth 2.0 concepts to delegate access with external services while using JWT as a bearer to transport claims from the authorization server to resource servers for stateless authorization.

JWTs allow client-side introspection of ID tokens, enable resource server serving APIs to verify access tokens locally, and even be used as refresh tokens. Although slightly controversial, JSON web tokens are versatile and can be used as one-time token (OTT).

The Purpose of JWT: Stateless Authentication

Fri, 28 Apr 2017 00:00:00 +0200

The demand for reliable and effective authentication methods has increased in the modern, distributed, and fast-paced digital world. Stateless authentication solutions are being used by developers and identity providers to deliver secure and scalable single sign-on solutions. JSON Web Token (JWT) are the new fancy kids around the block when it comes to transporting proofs of identity within an untrusted environment like the web.

Stateless Sessions Thanks to JSON Web Token #

While there are many articles that describe specific aspects, best practices or single use-cases of JWTs, the bigger picture and the actual problem definition is often missing. With JWTs gaining in popularity, that missing knowledge of the fundamental ideas of JSON Web Token leads to questions:

In this article, I describe the true purpose of JWT tokens – Getting rid of stateful authentication! – and compare classical, stateful sessions with modern, stateless authentication. Let’s start now!

What is JWT? #

Definition #

JSON Web Tokens are a self-contained, URL-safe way of conveying data, unique identifier and claims between two parties in an untrusted environment. They are frequently employed in online applications for the purposes of authentication and authorization of users, transporting proof of authenticity between an identity provider and relying parties.

Components of JWT tokens #

JWTs carry claims that are encoded as JSON object as the payload of a JSON Web Signature (JWS) structure or of a [JSON Web Encryption (JWE)] (https://www.janbrennenstuhl.eu/jwe/ “JWE Token: A Comprehensive Guide”) structure, allowing the claims to be encrypted and/or digitally signed in order to protect their integrity. A signed JWT is made up of three components: a header, a payload, and a signature. The header contains metadata, like the type of token and signing algorithm. The claims are stored in the payload and hold details about the particular user and other necessary data. Finally, the signature is used to affirm the token’s integrity.

Parts of a signed JWT

The Need for Stateless Authentication #

Stateless authentication is essential for modern web applications because it eliminates the need for the central authentication server to retain session id and session information. Ideally, this minimizes backend load and enables more effective application scaling. By removing bottlenecks, a decentralized authorization approach is said to simplify system landscape.

Stateful Authentication #

In the old days of the web, authentication was a purely stateful affair. With a centralized overlord entity being responsible for tokens, the world is fairly simple:

Tokens are issued and stored as stateful session data in a single service for future checking and revocation.
Clients and resource servers know a single point of truth for token verification and information gathering.

This works rather well in a world of integrated systems, where servers render frontends and dependencies exist on package-level rather than distributed applications.

In a world where applications are composed by a zoo of microservices however, this stateful authentication approach comes with a couple of serious drawbacks:

No service can operate without a synchronous dependency towards the central token store.
The token overlord, storing session data, becomes an infrastructural bottleneck and a single point of failure.

Both facts oppose the fundamental ideas of a stateless services landscape. Stateful authentication introduces not just another dependency for all your single-purpose services (network latency!) but also makes them heavily rely on access to it. Without the full session information and data database being available, authorization decisions can’t be taken anymore and everything is doomed.

Stateless Authentication #

Stateless token-based authentication describes a system or process, that enables its components to decentrally verify and introspect tokens. This ability to delegate session token verification allows to (partially) get rid of the direct coupling to a central session data database and in that way enables state transfer for authentication proves. The benefits are clear:

Less latency through service-local, decentralized token verification and authorization decisions.
Increased resilience through less network overhead.

Stateless authentication is also able to absolve you from the need to keep track of issued tokens and for that reason removes state (and hence reduces storage) dependencies from your system. The antiquated, heavy-weighted token overlord solution converges to to yet another microservice being mainly responsible for authentication and token issuing.

Stateful vs. Stateless #

Today, an authentication system has to support stateless architecture service landscapes mainly characterized by fleets of thousands of services and millions of actors. Central bottlenecks by design become an operational burden. However there are no silver bullets, JWTs ain’t Swiss army knifes and also stateful authentication has its righteous place.

If you really need a central authentication system to persist session data or if you simply don’t trust people or library source code to correctly verify session information in your JWTs, a stateful overlord approach is still the way to go and there is nothing wrong about it.

The World becomes Stateless - Google Trends

How JWT Enables Stateless Authentication #

Token-based authentication #

Stateless authentication get enabled through the use of stateless tokens (JWT). The authentication server generates these token, which are self-contained and carry all necessary details about the session and the user. In order to avoid the backend from having to keep track of any session ID and session data, the client stores this token and includes it in subsequent requests.

JSON Web Signature (JWS) #

To guarantee the authenticity and integrity of the token, JWT session token must always use JWS. Because the private key material used to create this digital signature is only known to the server, it prevents unauthorized modification of the token.

Pros and Cons of Stateless Authentication with JWT #

Advantages #

Scalability: Stateless authentication removes architectural bottlenecks, can reduce server load and allows for easier horizontal scaling.
Performance: Less server overhead means faster response times.
Simplified architecture: No need to manage sessions stored server-side.

Disadvantages #

Token size: Due to their metadata overhead, JWTs are generally larger than traditional session cookies, increasing bandwidth usage.
Token theft: If a token is stolen, it can be used until it expires, posing a security risk.

Understanding JWT Workflow #

One popular way to achieve stateless authentication is defined in RFC 7523 and leverages the OAuth 2.0 Authorization Framework (RFC 6749) by combining it with signed JWT (RFC 7519, RFC 7515). Instead of storing the token-to-principal relationship in a database in a stateful manner, cryptographic signatures allow decentralized clients to securely store and grant access, without need to retrieve data from a central system for every inbound request.

Stateless tokens are also a key component of OpenID Connect (OIDC), an identity layer solution built on top of the OAuth 2.0 protocol. OpenID Connect specifies industry-standard flows that allow clients to access basic profile information about the end-user in an interoperable way and to confirm the end-user’s identity based on the authentication carried out by an authorization server.

“Using a JWT as a bearer for authorization, you can statelessly verify if the user is authenticated by simply checking if the expiration in the payload hasn’t expired and if the signature is valid.” — Jonatan Nilsson

With tokens not being opaque but locally introspectable, clients can retrieve addition information about the corresponding identity directly from the token without the need of calling another remote API. The following is a simplified, non-normative lifecycle example of a stateless JWT.

Token Creation #

The user submits their credentials (e.g., username and password) to the authentication system.
The server authenticates the actor by verifying the credentials and generates a JWT containing user-related claims.
The server signs the token using a private key and returns it to the client side.

Token Verification #

The client includes the JWT as bearer token within the Authorization header in subsequent requests.
The resource server verifies the token’s signature and validates the claims.
If the token is valid and authorization successful, the resource server processes the request and returns the appropriate response.

Token Expiration #

JWTs typically include an expiration time to limit their validity.
Once the token expires, the client must request a new token by re-authenticating with the authorization server.

Use Cases for JWT #

Authorization: Securely authorize actors based on user claims like roles and permissions without relying on server-side sessions.
Information Exchange: Securely transmit information between parties in untrusted environments.

Security Concerns & Considerations #

Token storage: Store tokens in a secure location on the client side, such HttpOnly cookies or other safe places.
Transport security: Use HTTPS to protect tokens from being intercepted during transmission.
Token revocation: By design, JWTs are not remotely revokable. To revoke tokens in case of token theft or user logout requires, a stateful mechanism to be in place – which sort of counters the stateless approach.
Token update: There is no way of altering an issued JWT. Prolongating its expiration date for example is not possible.

Best Practices for JWT Implementation #

Use short expiration times: Limit the window of opportunity for token theft.
Rotate private keys: Regularly update the signing key to mitigate risks associated with key compromise.
Validate tokens: Before processing requests, always check the tokens validity on the authorizing backend.

Conclusion #

In modern web applications, JWTs offer a reliable and adaptable stateless authentication method. Developers may create secure, scalable, and effective apps that satisfy the requirements of today’s digital ecosystem by utilizing their advantages and following best practices.

FAQs #

What is the main purpose of using JWT in stateless authentication? #

The major goal is enhanced scalability and performance by securely authorizing users without relying on server-side sessions.

How can I prevent JWT theft? #

Tokens must be stored securely on the client side and transmitted encrypted using HTTPS. If stateful revocation procedures are not implemented, tokens should have a short expiration time.

Can I use JWT for authorization as well as authentication? #

JWTs can function as bearer tokens. Authorization decisions can be made either purely on token validity or take into consideration claims carried by the token.

Do I need to store JWT session data in a database? #

No, JWTs are self-contained and do not require server-side storage. Actually that would be an anti-pattern.

How do I handle JWT expiration? #

Implement a mechanism for clients to request a new token when the existing one expires. OAuth 2.0 for example distinguishes between access token and refresh token and defines protocols on how to continuously refresh tokens without need to actively re-authenticate the user.

Single-Use JWT: Unlocking the Power of Stateless One Time Token

Fri, 30 Dec 2016 00:00:00 +0100

Understanding JSON Web Tokens #

Welcome to the future of authentication! In a world where digital security is paramount, the need for robust and reliable authentication methods has never been more crucial. JSON Web Tokens are the new and fancy de-facto standard in the web. JWTs are the tool of choice when it comes to authentication in an stateless environment. That has two direct implications:

You should definitely go and get some proper introduction on the purpose of JSON Web Tokens and some insights on how they work. It’s worth to know as JWTs are widely used for e.g. authentication against REST-APIs.
As JWTs are still comparably fresh, hot and simply fancy in contrast to traditional bearer token, some people think they are some kind of holy grail and can be used to solve every possible use-case … and guess what: They are not!

In this article, I will dive into the benefits of single-use JWTs, how they work, and best practices for implementing them in your application. Get ready to unlock the full potential of stateless authentication with single-use JWTs!

What are JSON Web Tokens? #

JSON Web Tokens are an industry standard method for exchanging claims securely between two parties. They are defined as an open standard in RFC 7519 but only become truly powerful in combination with RFC 7515, which describes JSON Web Signatures (JWS). In combination, the two standards allow the creation of a cryptographically signed json object that carries state and can get verified, which basically means that you have means to ensure that a JWT is valid and created by someone you have faith in before you trust it.

Being self-contained, stateless and signed, JWT tokens allow you to leverage so-called stateless authentication, mostly in form of bearer tokens within an authorization header (access token), issued by an authorization server in context of OAuth 2.0 or OpenID Connect (OIDC).

But there are further information exchange use cases for standardised, signed tokens that can carry state between some other client side and a server or two servers. One example, I saw being discussed in the open wild and also within companies, is to use a JWT token as one-time token (OTT).

The Power of JSON Web Token #

While not being a Swiss army knife, the power of JSON Web Tokens lies in their ability to unlock a multitude of benefits especially for authorization servers, identity provider servers and system reliability. From my point of view, the key features that make JWTs a force to be reckoned with in the world of digital security, is their support of stateless architecture. Unlike traditional session-based authentication mechanisms, JWTs are stateless by design. This means that servers do not necessarily need to store any session-related information in their database, resulting in improved scalability and reduced server-side complexity.

Another side-effect of the general hype around these stateless tokens, is their interoperability. JWTs have gained widespread adoption and support across different programming languages, frameworks, and platforms. Every niche has their own JWT library. This interoperability ensures seamless integration into existing systems and promotes interoperability between various components of a distributed application. JWT token basically standardised the data format of access tokens or session token.

What Is a One Time Use Token? #

A One Time Use Token, also known as a single-use token, is a unique and disposable identifier that is generated for a specific transaction or interaction. Unlike traditional tokens or credentials that can be reused multiple times, a one-time use token serves a singular purpose and becomes invalidated or expired after its initial use.

The primary purpose of a one-time use token is to enhance security and reduce the risk of unauthorized access or fraudulent activities. By limiting the token’s usability to a single instance, it significantly mitigates the chances of interception, replay attacks, or unauthorized reuse. This makes one-time use tokens an invaluable tool in various domains, including authentication systems, payment processing, and secure communication protocols.

Advantages of Single-Use Token Validation #

One-time use tokens are typically generated through a cryptographic algorithm or hash function, ensuring their uniqueness and tamper-resistant properties. Once generated, the token is associated with a specific transaction or user session, providing a temporary authorization credential that grants access to protected resources or validates an action. Once it fulfils its intended purpose, the token expires and becomes invalid, ensuring that any subsequent attempts to use or manipulate it are rendered ineffective.

The advantages of one-time use tokens extend beyond just security. They also offer enhanced traceability and auditability, as each token can be easily tracked and linked to a specific event or transaction. This attribute becomes particularly valuable in scenarios where accountability and compliance are crucial, such as financial transactions or regulatory environments.

Implementing One-Time JWT Token #

Let’s talk about use-cases: Imagine you have a setup based on OAuth 2.0 that uses signed JWTs as bearer tokens for user-auth. Further imagine you want to provide account recovery via password-reset by email with confirmation-link included. For that confirmation-link we would then need to have some kind of proof attached as query param to the URI. As the password-reset should work only once, the token is required to get invalided after successful usage. Hence, we would need the shared secret to have OTT characteristics.

One solution could be a storage holding issued tokens and validity information. Every incoming password-reset request for the protected resource that the reset-link is targeting would then be authorized by the receiving web application against that central list. This so-called “stateful approach” introduces a single point of truth. The token storage becomes the central bottleneck.

It would be great if another solution could leverage existing concepts. For example our stateless authentication system with its ability to create, sign and verify JWTs …

Generating and Validating Tokens #

The solution for our problem is actually straightforward as it is based on a simple trick. Although we can’t (and don’t want to) alter issued JWTs, our resource server is still the master of verification. We just need to look at JSON Web Token verification from another angle – for example by using app-state as input secret for the HMAC algorithm during JWS issuing!

To stay in the example use case of account recovery that means, that using the users current password hash as secret key for the signing algorithm guarantees single-usage of every issued reset token. This is because the salted hash naturally always changes with a new input, which at the same time concludes the password-reset procedure successfully. There is no way the same token can pass verification twice. The signature checks in case of a replay of signed tokens would always fail.

Using private, server-side state, sensitive data that changes as an outcome of a business operation, to sign a JSON Web Token that is used to authorize the very same business operation, results in the JWT effectively becoming a one-time token.

How to use JWT as one-time-token OTT?

User Experience and Usability Challenges #

Especially in the context of email based password reset capabilities there is however technical risk attached: One of the drawbacks of JSON Web Tokens (JWTs) is their larger payload size compared to other token type. Since signed JWTs store information within the token itself, including metadata and a massive digital signature, the size can grow significantly. This can have implications, especially in scenarios where tokens are transmitted as query parameters.

Browsers impose a de-facto limit of 2000 characters for URIs and also email providers or clients appears to also struggle with large URIs. As many email links already include a zoo of e.g. tracking IDs, you definitely want to think and test twice before deciding to put a JWT into a query param.

Security Issues & Risks #

Besides the regular security issues of JSON Web Token that largely resided with insufficient implementations on the signature verification, combining JWT and OTT characteristics does not introduce any new attack vectors. Both, authorization server and resource server have to perform the same tasks, whether they implement JWT or not.

Embracing the Future of Stateless One-Time Tokens #

So let’s sum up our findings on how to implement single-use tokens based on JWT:

There is no need to setup some kind of token-registry storage. This would counter the idea of stateless tokens anyway.
Instead, compose signature secrets based on values that change after each token usage. In other words: Turn app state into HMAC-keys to guarantee one-time use of JWTs!

Although in theory, this might also work for other use-cases like email verification or account confirmation, my thoughts took shape while reasoning about account recovery approaches. Furthermore, I do believe this to be a rather academical exercise and that we won’t see this getting widely adapted in the open wild.

What do you think? Let me know via Mastodon and also make sure to share your exotic use cases for JSON web tokens and one-time token approaches with me. I also appreciate feedback and further discussion, thanks!

Tokens & JWT · Brennenstuhl on Security

What is inside a JWT?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

Try it #

Decode a token in your browser

How the parts fit together #

Related #

What is JWA? A Deep Dive into JSON Web Algorithms

Definition of JWA #

Anatomy of JSON Web Algorithms #

Different Types of JSON Web Algorithms #

Understanding the Symmetric Key Algorithms #

Delving into Asymmetric Key Algorithms #

Practical Applications of JWA #

Conclusion #

Mastering JWKS: JSON Web Key Sets Explained

TL;DR #

Technical Specifications of JWK and JWKS #

What is JSON Web Key (JWK)? #

What is JSON Web Key Set (JWKS)? #

Locate JSON Web Key Sets #

Benefits of Using JWKS #

Easy Management of Keys with JWK Sets #

Simplified Key Rotation Process Using JWKs #

Compatibility with Various Protocols and Applications #

Best Practices & Security Considerations #

Use Transport Layer Security #

Make sure JWKS is correct and current #

Validate the signatures of incoming JWTs using JWKs #

Consider rotating your JWKS keys periodically #

Conclusion: The Importance of Using JSON Web Key Sets #

JSON Web Encryption: Exploring JWE Token

TL;DR #

JSON Web Encryption (JWE) Token: A Comprehensive Guide #

The Structure of an Encrypted JWT #

Support for Symmetric and Asymmetric Encryption Algorithms #

Nested JWTs #

Working with Different JWE Algorithms #

JWE with AES Algorithms #

JWE with RSA Algorithms #

JWE with Elliptic Curve Algorithms #

Authenticated Encryption Algorithms #

JWE Token Generation Process #

Encryption Algorithm: Choosing the Right One for Your Needs #

Generating Keys: Private Key vs Secret Key #

Complete JOSE Header #

Encryption & Serialization: Creating Valid JWE Tokens #

JWE Token Decryption Process #

Decoding the JWE Compact Serialization #

Key Decryption #

Payload Decryption #

Security Considerations #

Authentication Tag and Additional Authenticated Data #

Leaky Headers #

Key Management and Token Expiry #

Weak algorithms #

Comparison of JWE and Other JSON Security Standards #

JWE vs JWT #

JWE vs JWS (JSON Web Signature) #

JWE vs JWK (JSON Web Key) #

Practical Applications of JWE Tokens #

Bearer Token: A Powerful Authentication and Authorization Tool #

JWE in OAuth2 and OIDC #

JWE for Data at Rest #

Conclusion #

Frequently Asked Questions (FAQs) #

JWT vs OAuth 2.0: Understanding the Key Differences

TL;DR #

Introduction to JWT vs OAuth 2.0 #

What is OAuth2? #

What is JWT? #

When to Use OAuth 2.0 vs When to Use JWT #

Combining OAuth 2.0 and JWT: How to Use Them Together #

JWT as Bearer Token #

Advantages of Using JWT with OAuth 2.0 #

Which Bearer Token Format is Right for You? #