As a result of a successful authentication request, the OpenID Provider returns an ID Token in the form of a JSON Web Token, the specification for the JSON Web Token format can be found online at https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32. The ID Token contains claims about the authentication of an end-user as follows:
Issuer. A URL that identifies the OP.
Subject. Uniquely identifies the end-user
Audience. Contains the OAuth 2.0 client_id of the Relying Party.
Expiration time. Set by Cloud Access Manager by adding 30 minutes to the time the ID token was issued.
Time at which the ID Token was issued.
Time when the end-user authentication occurred.
If a nonce is present in the authentication request, the same value will be echoed to the client in this claim. The nonce value can be used by the client to mitigate replay attacks.
OpenID Connect requires that the ID Token must be digitally signed. Cloud Access Manager offers two ways to sign the ID Token. You can sign the ID Token:
Cloud Access Manager supports the following response types:
|code||OAuth v2.0 authorization code flow|
|token||OAuth v2.0 implicit flow||Not used by OpenID Connect (no ID token returned)|
|id_token||OpenID Connect implicit flow||No access token returned. Claims are included in the ID Token|
|token id-token||OpenID Connect implicit flow||Claims are accessed by invoking UserInfo endpoint|
Cloud Access Manager does not use the scope values contained in the authentication request to determine what claims are to be returned. Instead, it returns the claims defined by the application configuration’s claim mappings. Thus the client cannot control what claims are returned to it.