JSON Web Signature (JWS)

A JSON Web Signature (JWS) is a IETF standard (RFC 7515) for securing data, typically a JSON object, with a digital signature or a Message Authentication Code (MAC). It provides integrity protection and authenticity for the data, allowing a recipient to verify that the content has not been altered and originated from a known sender. The structure is composed of three Base64url-encoded parts separated by dots: a JOSE Header, the JWS Payload, and the JWS Signature. This compact serialization makes JWS ideal for use in web tokens, API security, and other stateless authentication protocols.

The JOSE Header contains metadata describing the cryptographic operations applied. It specifies the signing algorithm (e.g., RS256 for RSA with SHA-256 or HS256 for HMAC with SHA-256) and may declare the type of the payload via the typ parameter. The JWS Payload is the actual content being secured, which can be any sequence of bytes, though it is commonly a JSON Web Token (JWT) claim set. The JWS Signature is computed over the concatenation of the encoded header, a dot (.), and the encoded payload, using the algorithm and key specified in the header.

JWS supports two primary modes of trust: digital signatures using asymmetric cryptography (e.g., RSA, ECDSA) and MACs using symmetric keys (e.g., HMAC). Asymmetric signatures allow verification by anyone with the public key, enabling scenarios like issuer verification in OAuth 2.0 and OpenID Connect. Symmetric MACs require all parties to share a secret key and are used in contexts where a single entity both creates and validates the signature. The standard also defines a JSON Serialization format for environments where the compact, dot-separated string is not suitable.

In practice, JWS is the foundational security layer for JSON Web Tokens (JWTs), where the JWS secures the JWT claims. It is widely deployed in modern web security for access tokens, identity tokens, and securing API requests. When a system receives a JWS, it must validate the signature using the correct key, verify the algorithm is allowed, and check the token's expiration and other claims within the payload to prevent security vulnerabilities like algorithm confusion attacks.

A JSON Web Signature (JWS) is a compact, URL-safe means of representing a digitally signed payload, typically a JSON object, using JSON data structures. The core process involves three steps: creating a JOSE Header specifying the signing algorithm, computing a digital signature over the combined header and payload, and serializing the result into either a Compact Serialization (a three-part, dot-separated string) or a JSON Serialization (a JSON object). This signature allows any party with the appropriate public key to verify that the payload has not been tampered with and was signed by the holder of the corresponding private key.

The signing process is defined by the JWS Signing Input, which is the concatenation of the Base64url-encoded JOSE Header, a period (.), and the Base64url-encoded payload. The specified digital signature algorithm (e.g., RS256, ES256, HS256) is then applied to this input string using the signer's private or secret key. Common algorithms include RSA with PKCS#1 v1.5 or PSS padding, Elliptic Curve Digital Signature Algorithm (ECDSA), and HMAC with SHA-2 for symmetric key scenarios. The resulting signature is also Base64url-encoded for inclusion in the final JWS structure.

For verification, the recipient decodes the JWS, recomputes the JWS Signing Input from the received header and payload, and verifies the signature using the algorithm specified in the alg header parameter. Successful verification cryptographically proves the integrity of the payload and header, and, when asymmetric cryptography is used, the authenticity of the signer. The JOSE Header may also contain other protected metadata, such as a key ID (kid) to indicate which key was used, which is critical for key rotation in systems like OAuth 2.0 and OpenID Connect.

JWS supports two serialization formats to accommodate different use cases. The Compact Serialization (header.payload.signature) is optimized for space and is commonly used in HTTP headers (e.g., Bearer tokens). The JSON Serialization produces a JSON object with payload, signatures (an array), and protected/header fields, enabling features like multiple signatures or unprotected headers. This flexibility makes JWS a foundational standard for securing API communications, identity tokens, and any data exchange requiring verifiable provenance.

A JSON Web Signature (JWS) is a compact, URL-safe means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. The JWS Serialization Formats define how the core components—the JWS Protected Header, JWS Payload, and JWS Signature—are assembled for transmission. The IETF RFC 7515 standard specifies two primary formats: the Compact Serialization and the JSON Serialization, each serving distinct use cases in web security, API authentication, and verifiable credentials.

The Compact Serialization is the most common format, producing a single, condensed string ideal for HTTP headers (like the Authorization: Bearer token) or URL query parameters. It concatenates the base64url-encoded Protected Header, Payload, and Signature, separated by period (.) characters, resulting in a structure like eyJhbGciOiJ.... This format is compact and widely supported but is limited to a single digital signature or MAC per JWS, using only a JWS Protected Header.

In contrast, the JSON Serialization represents the JWS as a JSON object, providing greater flexibility. This format supports multiple signatures or MACs over the same payload, enabling complex scenarios like multi-party signing. The JSON structure contains members such as payload, signatures (an array of signature objects), and optionally a protected header. Each signature object within the array can have its own set of header parameters (protected and/or header), allowing for different algorithms or keys to be applied to the same payload.

The choice between formats depends on the application's requirements. Compact Serialization is preferred for its simplicity and efficiency in token-based authentication (e.g., JWT). JSON Serialization is necessary for advanced features like JWS JSON Serialization with Unencoded Payload (RFC 7797), where the payload is included as a non-base64url-encoded JSON value, or when detached content is used, allowing the payload to be transmitted separately from the signature for efficiency with large payloads.

Understanding these formats is crucial for implementing secure data exchange. Developers must correctly encode and decode the JOSE Header parameters, handle the base64url encoding as specified, and validate signatures according to the algorithm specified in the alg header. Proper implementation ensures data integrity, authenticity, and non-repudiation in systems ranging from OAuth 2.0 and OpenID Connect to blockchain transactions and digital document signing.

A JSON Web Signature (JWS) is a cryptographic mechanism defined in RFC 7515 for securing data, typically a JSON Web Token (JWT), with a digital signature or Message Authentication Code (MAC). It provides integrity protection and authenticity for the signed payload, allowing a recipient to verify that the content has not been altered and originated from a trusted source. The JWS structure is the fundamental security layer that transforms a plain JSON object into a verifiable token.

The relationship between JWS and JWT is hierarchical: a JWT is the abstract concept of a set of claims, while a JWS is one of two concrete serialization formats (the other being JWE for encryption) used to realize a JWT. In practice, when developers refer to a "signed JWT," they are almost always describing a JWT secured with a JWS. The JWS specification defines the exact structure—comprising a header, payload, and signature—that is base64url-encoded to produce the familiar compact string format (e.g., eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...).

The JWS header contains metadata critical for processing, most importantly the alg (algorithm) parameter, which specifies the signing algorithm (e.g., RS256, HS256, ES256). The payload is the JWT Claims Set—the actual data being secured. The signature is computed over the concatenated base64url-encoded header and payload. This design ensures that any tampering with the header or payload invalidates the signature, making JWS essential for secure authentication and authorization in protocols like OAuth 2.0 and OpenID Connect.

It is crucial to distinguish JWS from JSON Web Encryption (JWE), which provides confidentiality instead of integrity. While a JWS can be nested within a JWE for both signing and encryption, a JWT is most commonly implemented as a JWS. Understanding this relationship is key for developers implementing secure APIs, as proper algorithm selection (alg) and key management are dictated by the JWS standard to prevent vulnerabilities like algorithm confusion attacks.