T
jwt jose rfc7515 rfc7519 security authentication standards

JOSE and JWT Standards: RFC 7515 to 7519 (JWS, JWE, JWK, JWA, JWT)

A deep dive into the JOSE stack. Learn about RFC 7515 (JWS), 7516 (JWE), 7517 (JWK), 7518 (JWA), and 7519 (JWT) for secure identity tokens.

2026-04-11

JOSE and JWT Standards: RFC 7515 to 7519

If you've ever implemented modern web authentication, you've likely used JSON Web Tokens (JWT). But JWT is just one piece of a larger family of standards known as JOSE (JSON Object Signing and Encryption). Understanding the relationship between these standards is crucial for building secure applications.

In this guide, we'll explore the five core RFCs that make up the JOSE stack:

  • RFC 7515: JWS (JSON Web Signature)
  • RFC 7516: JWE (JSON Web Encryption)
  • RFC 7517: JWK (JSON Web Key)
  • RFC 7518: JWA (JSON Web Algorithms)
  • RFC 7519: JWT (JSON Web Token)

1. RFC 7515: JSON Web Signature (JWS)

JWS is the most common form of JWT. It ensures that the content of the token hasn't been tampered with. It provides integrity and authenticity, but not confidentiality (the content is still visible to anyone who sees the token).

Structure:

A JWS is typically represented in Compact Serialization format, which has three parts separated by dots: BASE64URL(Header) . BASE64URL(Payload) . BASE64URL(Signature)

  • Header: Specifies the algorithm used for signing (e.g., {"alg": "HS256"}).
  • Payload: The actual data being signed.
  • Signature: The result of signing the header and payload.

2. RFC 7516: JSON Web Encryption (JWE)

While JWS provides integrity, JWE provides confidentiality. It encrypts the payload so that only the intended recipient can read it.

Structure:

JWE Compact Serialization has five parts: BASE64URL(Header) . BASE64URL(Encrypted Key) . BASE64URL(Initialization Vector) . BASE64URL(Ciphertext) . BASE64URL(Authentication Tag)

JWE is often used when the token contains sensitive information, such as PII (Personally Identifiable Information), that should not be visible to the client or intermediate proxies.

3. RFC 7517: JSON Web Key (JWK)

A JWK is a JSON data structure that represents a cryptographic key. It is used to share public keys between servers in a standardized way.

Example:

{
  "kty": "RSA",
  "use": "sig",
  "kid": "1b94c",
  "n": "vXl...",
  "e": "AQAB"
}

A collection of JWKs is called a JWKS (JSON Web Key Set), often found at an endpoint like /.well-known/jwks.json.

4. RFC 7518: JSON Web Algorithms (JWA)

JWA is the "dictionary" for the JOSE stack. It defines the specific algorithms used for signing (JWS) and encryption (JWE).

Common Algorithms:

  • HS256: HMAC using SHA-256 (Symmetric).
  • RS256: RSASSA-PKCS1-v1_5 using SHA-256 (Asymmetric).
  • ES256: ECDSA using P-256 and SHA-256 (Asymmetric).
  • A128GCM: AES GCM using 128-bit key (Encryption).

5. RFC 7519: JSON Web Token (JWT)

JWT is an application of JWS or JWE where the payload is a set of claims. Claims are pieces of information about an entity (typically a user).

Standard Claims:

  • iss: Issuer
  • sub: Subject (User ID)
  • aud: Audience
  • exp: Expiration Time
  • iat: Issued At

Summary Comparison

Standard Purpose Analogy
JWS Integrity A signed letter
JWE Confidentiality An encrypted envelope
JWK Key Representation A public key file
JWA Algorithm Catalog A cipher list
JWT Data Format The actual token

FAQ

Q: Is a JWT always a JWS? A: Not always, but in 99% of cases, yes. A JWT can be a JWS (signed), a JWE (encrypted), or even an unsecured JWT (no signature).

Q: Should I use RS256 or HS256? A: RS256 (Asymmetric) is generally preferred for identity tokens because it allows the client to verify the signature without needing the private key used to sign it. HS256 (Symmetric) is faster but requires sharing the secret.

Q: Where can I see what's inside a JWT? A: Since JWS payloads are only Base64 encoded, you can decode them easily. However, you should never trust the data unless you have verified the signature.

Related Tools

Back to Blog