JOSE
What is JOSE?
JOSEJavaScript Object Signing and Encryption: an IETF family of standards (RFC 7515-7520 and 8037) for representing signed and encrypted data using JSON.
JOSE is the umbrella term for the IETF specifications that bring cryptographic protection to JSON-based protocols. It comprises JWS (RFC 7515) for signatures, JWE (RFC 7516) for encryption, JWK and JWK Set (RFC 7517) for key representation, JWA (RFC 7518) for algorithm identifiers such as RS256, ES256, EdDSA and A256GCM, JWT (RFC 7519) for claims-based tokens, plus the JSON-as-cryptographic-protocol guidance of RFC 7520. RFC 8037 added Ed25519 and X25519. JOSE underpins OAuth 2.0, OpenID Connect, SaaS API auth, and W3C Verifiable Credentials. Implementers must avoid the historical alg:none attack, key-confusion bugs between RS256 and HS256, and the encrypt-then-MAC vs AEAD pitfalls highlighted in CVE-2015-9235 and similar disclosures.
● Examples
- 01
An OpenID Connect ID token is a JWT (a JWS Compact Serialization) signed with RS256 or ES256.
- 02
An OAuth 2.0 DPoP proof is a short-lived JWS Compact JWT bound to a client key.
● Frequently asked questions
What is JOSE?
JavaScript Object Signing and Encryption: an IETF family of standards (RFC 7515-7520 and 8037) for representing signed and encrypted data using JSON. It belongs to the Cryptography category of cybersecurity.
What does JOSE mean?
JavaScript Object Signing and Encryption: an IETF family of standards (RFC 7515-7520 and 8037) for representing signed and encrypted data using JSON.
How does JOSE work?
JOSE is the umbrella term for the IETF specifications that bring cryptographic protection to JSON-based protocols. It comprises JWS (RFC 7515) for signatures, JWE (RFC 7516) for encryption, JWK and JWK Set (RFC 7517) for key representation, JWA (RFC 7518) for algorithm identifiers such as RS256, ES256, EdDSA and A256GCM, JWT (RFC 7519) for claims-based tokens, plus the JSON-as-cryptographic-protocol guidance of RFC 7520. RFC 8037 added Ed25519 and X25519. JOSE underpins OAuth 2.0, OpenID Connect, SaaS API auth, and W3C Verifiable Credentials. Implementers must avoid the historical alg:none attack, key-confusion bugs between RS256 and HS256, and the encrypt-then-MAC vs AEAD pitfalls highlighted in CVE-2015-9235 and similar disclosures.
How do you defend against JOSE?
Defences for JOSE typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for JOSE?
Common alternative names include: JavaScript Object Signing and Encryption.
● Related terms
- cryptography№ 573
JWS
JSON Web Signature (RFC 7515) is a JOSE format that protects the integrity and origin of arbitrary content using a digital signature or MAC over a Base64URL-encoded header and payload.
- cryptography№ 571
JWE
JSON Web Encryption (RFC 7516) is a JOSE format that confidentially encapsulates a payload using authenticated encryption and either a key-wrapping or key-agreement scheme.
- cryptography№ 572
JWK
JSON Web Key, defined in RFC 7517, is a JSON object that represents a public or private cryptographic key for use in JOSE and OAuth-family protocols.
- identity-access№ 574
JWT (JSON Web Token)
Compact, URL-safe token format (RFC 7519) that carries signed JSON claims, widely used as access tokens, ID tokens, and session containers.
- identity-access№ 760
OpenID Connect (OIDC)
An identity layer built on top of OAuth 2.0 that lets clients verify a user's identity and obtain basic profile information via signed ID tokens.
● See also
- № 225COSE