JOSE, JWT, JWS, JWE: The Complete Token Format Guide for CDN Engineers

The JOSE (JSON Object Signing and Encryption) family of standards is the foundation of modern token-based authentication on the web. Yet the relationships between JWT, JWS, JWE, JWK, and JWA are frequently misunderstood. Engineers working on CDN architectures need a clear mental model of these standards to make sound decisions about token formats, signing algorithms, encryption schemes, and key management at the edge. This article provides that model, with a focus on the practical concerns that arise when tokens are validated across distributed edge nodes.

We will work from the ground up: starting with the abstract JWT specification, then examining the concrete JWS and JWE formats, followed by JWK for key representation and JWA for algorithm selection. Throughout, we will connect each concept to the specific challenges of CDN token authentication and edge-based zero-trust security.

The JOSE Specification Landscape

JOSE is not a single specification but a family of five related RFCs. Understanding their relationships is the first step toward using them correctly. JWT (RFC 7519) defines the abstract concept of a JSON-based claims container. JWS (RFC 7515) defines how to digitally sign or MAC a payload to ensure integrity. JWE (RFC 7516) defines how to encrypt a payload to ensure confidentiality. JWK (RFC 7517) defines how to represent cryptographic keys in JSON format. JWA (RFC 7518) defines the cryptographic algorithms used by JWS, JWE, and JWK. A JWT is always serialized as either a JWS or a JWE — JWT itself has no wire format. When engineers say "JWT," they almost always mean a JWS-serialized JWT.

JWT: The Abstract Claims Container

A JWT is a compact, URL-safe means of representing claims to be transferred between two parties. The claims are encoded as a JSON object that is used as the payload of a JWS structure or as the plaintext of a JWE structure. A JWT is never transmitted in its raw JSON form — it is always wrapped in a JWS (for integrity) or a JWE (for confidentiality), or both (nested).

Standard Claims

JWT defines a set of registered claims that provide interoperability. iss (issuer) identifies who created the token. sub (subject) identifies the principal of the token. aud (audience) identifies the intended recipient(s). exp (expiration time) defines when the token expires. nbf (not before) defines when the token becomes valid. iat (issued at) indicates when the token was created. jti (JWT ID) is a unique identifier for the token, useful for preventing replay attacks.

For CDN edge validation, the iss, aud, and exp claims are the most critical. The edge function should verify that iss matches the expected authorization server, aud includes the CDN's client identifier, and exp is in the future (accounting for clock skew between edge nodes). These validation steps are detailed in our guide to JWT security best practices for distributed systems.

Custom Claims for CDN Use Cases

Beyond the standard claims, CDN tokens often include custom claims specific to content delivery. These might include a path claim restricting which URLs the token grants access to, a geo claim encoding geographic restrictions, an ip claim binding the token to a client IP address, or a rate claim specifying the client's rate limit tier. Custom claims should use namespaced names (such as cdn:path or a URL prefix) to avoid collisions with registered claims. This is particularly relevant for cache key design where token claims influence caching behavior.

JWS: Signed Tokens for Integrity and Authenticity

JWS is the serialization format for signed JWTs. The vast majority of tokens in production OAuth deployments are JWS tokens. A JWS consists of three parts, separated by periods: the header, the payload, and the signature. Each part is Base64URL-encoded.

JWS Structure

The header (JOSE Header) is a JSON object specifying the signing algorithm (alg) and optionally the key identifier (kid), key type (kty), and token type (typ). The payload is the JWT claims set, Base64URL-encoded. The signature is computed over the ASCII representation of BASE64URL(header).BASE64URL(payload) using the specified algorithm.

eyJhbGciOiJSUzI1NiIsImtpZCI6ImVkZ2Uta2V5LTEiLCJ0eXAiOiJKV1QifQ   -- Header
.
eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyXzEy -- Payload
MzQiLCJhdWQiOiJjZG4uZXhhbXBsZS5jb20iLCJleHAiOjE3Mjc4MjI0MDAsImlh
dCI6MTcyNzgxODgwMCwiY2RuOnBhdGgiOiIvdmlkZW8vKiJ9
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c                         -- Signature

A critical point: the payload of a JWS is not encrypted. Anyone with access to the token can decode the Base64URL payload and read the claims. JWS provides integrity (the claims cannot be modified without invalidating the signature) and authenticity (the signature proves the token was issued by the holder of the signing key), but not confidentiality. If the claims contain sensitive information, JWE must be used instead or in addition.

Choosing a JWS Algorithm

The algorithm choice for JWS has significant implications for CDN edge performance and security. The three main families are HMAC (symmetric), RSA (asymmetric), and ECDSA/EdDSA (asymmetric, elliptic curve). For CDN deployments, asymmetric algorithms are strongly preferred because they separate signing (private key at origin) from verification (public key at edge). This means edge nodes only need the public key and cannot forge tokens even if compromised.

RS256 (RSASSA-PKCS1-v1_5 with SHA-256) is the most widely supported algorithm. RSA signatures are larger (256 bytes for 2048-bit keys) and verification is slower than ECDSA, but it is supported by virtually every JWT library. ES256 (ECDSA with P-256 and SHA-256) produces much smaller signatures (64 bytes) and verifies faster than RS256, making it better suited for bandwidth-constrained edge scenarios. EdDSA (Ed25519) offers the best combination of security, performance, and signature size, but has slightly less library support. All three are excellent choices for edge function deployments; ES256 and EdDSA are preferred when edge compute resources or bandwidth optimization are concerns.

Never use HS256 (HMAC with SHA-256) in distributed CDN environments. HMAC is a symmetric algorithm: the same secret key is used for both signing and verification. This means every edge node that validates tokens must hold the signing secret, and any compromised edge node can forge tokens. Avoid the none algorithm entirely; it has been the source of numerous security vulnerabilities where attackers modify the algorithm header to bypass signature verification.

JWE: Encrypted Tokens for Confidentiality

While JWS protects token integrity, JWE protects token confidentiality. A JWE token ensures that only the intended recipient can read the claims. The payload is encrypted, and only the holder of the decryption key can access the contents. JWE is essential when tokens contain sensitive data that should not be visible to edge nodes, intermediate proxies, or anyone who intercepts the token in transit beyond the TLS layer.

JWE Structure

A JWE in compact serialization has five parts, separated by periods: the header, the encrypted key, the initialization vector (IV), the ciphertext, and the authentication tag. This is more complex than JWS because encryption requires key management (how the content encryption key is delivered to the recipient) in addition to the actual content encryption.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0   -- Header
.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe -- Encrypted Key
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zct1q3cYIkBWKmBBanPNXv_oCjpLnQoNRshSMskEKA
.
48V1_ALb6US04U3b                                                     -- IV
.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji -- Ciphertext
SdiwkIr3ajwQzaBtQD_A
.
XFBoMYUZodetZdvTiFvSkQ                                               -- Auth Tag

Two Layers of Encryption

JWE uses two layers of encryption. The content encryption algorithm (specified by the enc header parameter) encrypts the actual payload using a randomly generated Content Encryption Key (CEK). The key management algorithm (specified by the alg header parameter) encrypts or wraps the CEK so that only the intended recipient can recover it. This two-layer approach allows the use of efficient symmetric algorithms (like AES-GCM) for the payload while using asymmetric algorithms for key delivery.

For CDN deployments, the recommended combination is RSA-OAEP-256 or ECDH-ES+A256KW for key management and A256GCM for content encryption. This provides strong security with good performance characteristics. The ECDH-ES family is preferred for new deployments because it produces smaller encrypted keys and aligns with modern cryptographic best practices for TLS 1.3 key exchange.

When to Use JWE at the CDN Edge

In most CDN authentication scenarios, JWS is sufficient. Edge nodes need to read the token claims to make authorization decisions (checking the path, audience, and expiration). JWE adds complexity and prevents edge nodes from inspecting the claims without the decryption key. Use JWE in these scenarios: when tokens contain PII that edge nodes should not access, when tokens travel through untrusted intermediate proxies beyond your CDN, when regulatory requirements mandate payload encryption (GDPR, HIPAA), or when you need to pass sensitive data (internal user roles, billing tiers) through the token without exposing it to the CDN layer.

Nested Tokens: JWS Inside JWE

When you need both integrity and confidentiality, the standard approach is to nest a JWS inside a JWE. You first sign the claims (creating a JWS), then encrypt the entire JWS as the JWE payload. The recipient decrypts the JWE to obtain the JWS, then verifies the JWS signature. This is signaled by setting the cty (Content Type) header in the JWE to JWT.

Nested tokens are particularly useful in CDN architectures where the origin creates tokens and edge nodes forward them. The origin signs the claims with its private key (ensuring integrity and authenticity) and encrypts them with the edge node's public key (ensuring only that specific edge node or the origin can read them). This pattern is relevant for origin protection scenarios where the origin needs to pass sensitive configuration to specific edge nodes via the token payload.

JWK and JWKS: Key Management at the Edge

JWK (JSON Web Key) defines how cryptographic keys are represented in JSON format. A JWK includes the key type (kty), the key's public components (modulus and exponent for RSA; x and y coordinates for EC), a key identifier (kid), the intended use (use: "sig" for signing, "enc" for encryption), and allowed algorithms (alg). JWKS (JSON Web Key Set) is a JSON object containing an array of JWKs under the keys property.

JWKS Endpoints and CDN Caching

Authorization servers publish their public keys at a well-known JWKS endpoint (typically /.well-known/jwks.json or discovered via the OpenID Connect discovery document). CDN edge nodes must fetch and cache these keys to validate JWS tokens locally. The caching strategy is critical: too short a TTL means frequent origin requests; too long a TTL delays key rotation. A recommended approach is to cache the JWKS with a 5 to 15 minute TTL, with a fallback strategy: if a token's kid does not match any cached key, the edge node fetches the JWKS again before rejecting the token. This handles key rotation gracefully without excessive origin load.

This JWKS caching pattern integrates naturally with your CDN's existing HTTP caching infrastructure. The JWKS endpoint should return appropriate Cache-Control headers, and the edge function can use the CDN's cache API to store and retrieve the key set. Be cautious about caching the JWKS in a shared cache that other users can access; the cache entry should be keyed to the JWKS URL and not derivable from user-controlled input.

Key Rotation Without Downtime

Key rotation is a regular operational necessity (for security hygiene and in response to potential key compromise). The JWKS mechanism makes rotation seamless. The process is: generate a new key pair, add the new public key to the JWKS (alongside the old key), start signing new tokens with the new key (referencing its kid in the JWS header), wait for all tokens signed with the old key to expire (typically one access token lifetime), and finally remove the old key from the JWKS. During the transition, edge nodes will see tokens with both old and new kid values and can verify both because both keys are in the cached JWKS.

For CDN environments, coordinate key rotation with your edge cache TTL. After adding the new key to the JWKS, wait at least one full cache TTL cycle before signing tokens with the new key. This ensures all edge nodes have fetched the updated JWKS containing the new key before they encounter tokens signed with it. Without this coordination, some edge nodes may reject valid tokens during the rotation window. The same principle applies to mutual TLS certificate rotation.

Compact vs. JSON Serialization

Both JWS and JWE support two serialization formats: compact and JSON. Compact serialization is the period-delimited format we have discussed (three parts for JWS, five for JWE). JSON serialization wraps the same data in a JSON structure, which supports features like multiple signatures (for JWS) or multiple recipients (for JWE).

For CDN token authentication, compact serialization is almost always the correct choice. It is URL-safe, compact (no JSON overhead), and supports a single signer/recipient, which is the common case. JSON serialization is useful in server-to-server scenarios where a token needs to be verified by multiple parties with different keys, but this is rare in CDN architectures. HTTP headers and cookies, the two primary transport mechanisms for CDN tokens, work naturally with the compact format.

Security Best Practices for CDN Token Implementation

Algorithm Validation

Always validate the alg header parameter against an explicit allowlist. Never trust the algorithm specified in the token header without verification. The "algorithm confusion" attack exploits implementations that naively use the header's alg value to select the verification algorithm. An attacker can change the algorithm from RS256 (asymmetric) to HS256 (symmetric) and sign the token with the public key (which is publicly available). If the server uses the header's algorithm and treats the public key as an HMAC secret, the forged token will verify successfully. Your edge function should have a hardcoded list of accepted algorithms and reject any token using an algorithm not on the list. This is one of the most common security vulnerabilities in JWT implementations.

Key ID Validation

The kid header parameter identifies which key from the JWKS should be used for verification. Always use the kid to select the verification key from your cached JWKS. Never fetch keys from URLs embedded in the token (such as the jku header), as an attacker could point this to their own key server. If your implementation supports the jku (JWK Set URL) header, restrict it to a strict allowlist of trusted URLs corresponding to your authorization servers.

Clock Skew Handling

Edge nodes across a global CDN may have slightly different system clocks. When validating the exp and nbf claims, allow a small clock skew window (typically 30 to 60 seconds). This prevents valid tokens from being rejected by edge nodes whose clocks are slightly ahead of the token issuer. However, do not make the skew window too large, as this extends the effective token lifetime and delays revocation. Monitor CDN performance metrics to identify edge nodes with significant clock drift and correct them through NTP configuration.

Token Size Considerations

JWS tokens grow with each additional claim. In CDN environments where tokens are transported via HTTP headers or cookies, size matters. HTTP headers exceeding 8KB can cause issues with some servers and proxies. Keep the claims set minimal: include only the claims needed for edge validation (iss, aud, exp, kid, and any CDN-specific claims like path restrictions). Move rarely-needed data to the token introspection endpoint, which the origin can query when needed. Use ES256 or EdDSA instead of RS256 to reduce the signature size. These considerations are part of the broader performance optimization strategy for CDN architectures.

Practical Patterns for CDN

Pattern 1: Edge-Validated Access Tokens (JWS)

The most common pattern. The authorization server issues JWS access tokens signed with its private key. Edge nodes cache the JWKS and verify tokens locally. This pattern enables sub-millisecond token validation at the edge with no origin round-trip. It works well with the API gateway pattern where the edge validates the token and the origin trusts the edge's validation result. The token's exp claim drives the rate limiting and access control decisions at the edge.

Pattern 2: Encrypted Tokens for Sensitive Payloads (JWE)

When tokens carry sensitive data, use JWE with the origin holding the decryption key. Edge nodes forward the encrypted token to the origin for validation and receive an authorization decision in response. This adds an origin round-trip but protects the payload from edge-level exposure. A hybrid approach caches the origin's authorization decision at the edge (keyed by the token's JWE header hash) for a short period, reducing the round-trip cost for repeated requests with the same token.

Pattern 3: Signed-then-Encrypted Tokens (Nested JWS/JWE)

For the highest security requirements, use nested tokens. The origin signs the claims (JWS), then encrypts them (JWE). This provides both authenticity (the claims came from the origin) and confidentiality (only the intended recipient can read them). In CDN architectures, this pattern is used for service-to-service authentication between the origin and specific edge nodes, for passing routing instructions through the token payload, or for implementing agent authorization in AI-enhanced CDN workflows.

JWA Algorithm Reference

JWA (RFC 7518) defines the algorithms available for JWS and JWE operations. Here is a concise reference for the algorithms most relevant to CDN deployments. For JWS digital signatures: RS256/RS384/RS512 (RSASSA-PKCS1-v1_5), PS256/PS384/PS512 (RSASSA-PSS, preferred over RS* for new deployments), ES256/ES384/ES512 (ECDSA), and EdDSA (Ed25519/Ed448). For JWE key management: RSA-OAEP/RSA-OAEP-256 (RSA with OAEP), A128KW/A256KW (AES Key Wrap), ECDH-ES/ECDH-ES+A128KW/ECDH-ES+A256KW (Elliptic Curve Diffie-Hellman), and dir (direct use of a shared symmetric key). For JWE content encryption: A128GCM/A256GCM (AES-GCM, recommended) and A128CBC-HS256/A256CBC-HS512 (AES-CBC with HMAC). These algorithm choices should be coordinated with your TLS configuration to maintain consistent security levels across the stack.

Frequently Asked Questions

What is the difference between JWT, JWS, and JWE?

JWT (JSON Web Token) is an abstract container format for claims. JWS (JSON Web Signature) is a JWT that has been digitally signed to ensure integrity and authenticity — the payload is readable by anyone but tamper-proof. JWE (JSON Web Encryption) is a JWT that has been encrypted to ensure confidentiality — only the holder of the decryption key can read the payload. Most tokens commonly called "JWTs" are actually JWS tokens. When you need both integrity and confidentiality, you nest a JWS inside a JWE. This distinction matters when designing CDN token validation logic at the edge.

When should CDN engineers use JWE instead of JWS?

Use JWE when the token payload contains sensitive information that must not be readable by intermediate parties — such as PII, internal user roles, or billing data. In CDN architectures, if edge nodes need to validate tokens but should not see the payload contents, use nested tokens: sign the claims (JWS), then encrypt the result (JWE) with a key only the origin holds. For most CDN access control scenarios where the token carries only a path restriction, audience, and expiration, JWS is sufficient and preferred for its lower complexity and edge-local validation capability.

How do JWK and JWKS work for key distribution in CDN environments?

JWK (JSON Web Key) is a JSON format for representing cryptographic keys. JWKS (JSON Web Key Set) is a collection of JWKs published at a well-known endpoint. CDN edge nodes fetch and cache the JWKS to validate JWS signatures locally, without contacting the authorization server for each request. The JWKS includes key identifiers (kid) so the edge node can match a token's header to the correct verification key, supporting seamless key rotation without service interruption.

What algorithms should be used for JWS and JWE in production?

For JWS signing, use RS256 for broad compatibility, ES256 for smaller signatures and better performance, or EdDSA for the best performance-to-security ratio. Avoid HS256 in distributed systems since it requires sharing the secret with all verifiers. For JWE, use RSA-OAEP-256 or ECDH-ES+A256KW for key encryption and A256GCM for content encryption. Never use "none" as an algorithm in production. These choices should align with your CDN security policy and monitoring capabilities.

How do you rotate JWK keys without causing token validation failures?

Key rotation uses the kid (Key ID) header parameter. Publish the new key in the JWKS alongside the old one. Start signing new tokens with the new key (using its kid). Edge nodes matching the kid to a JWKS entry will automatically use the correct key. After all tokens signed with the old key have expired, remove the old key from the JWKS. Edge nodes should cache the JWKS with a short TTL (5-15 minutes) and refresh on cache miss for an unknown kid. This process integrates with broader zero-trust key management practices at the CDN edge.