This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:

• Identity Broker Service in OpenID Connect: Supporting Multiple Identity Providers & Service Providers
• Identity Broker Service in SAML
• OpenID Connect AuthN & AuthZ
• Comparison of OpenID Connect with OAuth2.0 & SAML2.0
• Cross Domain Identity Patterns: Chained Federation & Service Broker

JSON Web Token (JWT)

OpenID Connect uses the JSON Web Token (JWT)

The OpenID Connect protocol [OpenID.Core] is a simple, REST/JSON- based identity federation protocol layered on OAuth 2.0. It uses the JWT and JOSE formats both to represent security tokens and to provide security for other protocol messages (performing signing and optionally encryption). OpenID Connect negotiates the algorithms to be used and distributes information about the keys to be used using protocol elements that are not part of the JWT and JOSE header parameters.

• iss REQUIRED. Issuer Identifier for the Issuer of the response
• sub REQUIRED. Subject Identifier
• aud REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value
• exp REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing
• iat REQUIRED. Time at which the JWT was issued
• auth_time Time when the End-User authentication occurred
• nonce String value used to associate a Client session with an ID Token, and to mitigate replay attacks
• acr OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied
• omr OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used
• azp OPTIONAL. Authorized party – the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party

JSON Object Signing and Encryption (JOSE)

JSON Object Signing and Encryption (JOSE) specifications

• JSON Web Algorithms (JWA)
• JSON Web Encryption (JWE)
• JSON Web Key (JWK)
• JSON Web Signature (JWS)

In the OpenID Connect context, it is possible for the recipient of a
   JWT to accept it without integrity protection in the JWT itself.  In
   such cases, the recipient chooses to rely on transport security rather than object security.
For example, if the payload is
   delivered over a TLS-protected channel, the recipient may regard the
   protections provided by TLS as sufficient, so JOSE protection would
   not be required.

   However, even in this case, it is desirable to associate some
   metadata with the JWT payload (claim set), such as the content type,
   or other application-specific metadata.  In a signed or encrypted
   object, these metadata values could be carried in a header with other
   metadata required for signing or encryption.  It would thus simplify
   the design of OpenID Connect if there could be a JOSE object format
   that does not apply cryptographic protections to its payload, but
   allows a header to be attached to the payload in the same way as a
   signed or encrypted object.