The client initiates the flow by directing the user's browser to the authorization endpoint, adding querystrings to the URI as follows:
|response_type:||Set to “token” to request that the Authorization Server initiate an Implicit Flow.|
|client_id:||A unique identifier generated by Cloud Access Manager for the client when the application definition is configured.|
|redirect_uri:||The URI which Cloud Access Manager will redirect the user’s browser to, when authorization processing is complete.|
|scope (optional):||Used to determine what resources are being requested from the Resource Server.|
|state (optional):||A value which the client can use to maintain state between request and callback. This can be used to prevent cross-site request forgery.|
Assuming the user grants access, Cloud Access Manager redirects the browser back to the client using the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment, for example.
Cloud Access Manager does not explicitly prompt the resource owner to approve the client’s request to access a resource. The user is assumed to have given his/her consent in an enterprise context, where resources are not owned by an individual, but by the organization of which that individual is a member.
When configuring your OAuth v2.0 application in Cloud Access Manager, you are required to select its Client Type. OAuth v2.0 specifies two client types: public and confidential. Your choice determines whether Cloud Access Manager will enforce authentication on the client connection.
Server-based applications (typically web applications) are capable of maintaining the confidentiality of secret information. Applications which run in this environment should be configured as confidential. Cloud Access Manager does authenticate confidential clients. When you configure your application as a confidential client, you must use the authorization code flow; Cloud Access Manager will return an error if an attempt is made to invoke Implicit flow from a confidential client.
OpenID Connect is a standard which defines how the identity of an end-user can be verified, and how claims about a user can be obtained. It is an extension to the OAuth v2.0 protocol.
OpenID Connect deals with scenarios where a user is authenticated using a browser (for example the authorization code and implicit code flows of the OAuth v2.0 specification). Clients signal to the authorization server that they wish to perform OpenID Connect authentication by setting the scope in the initial authorization request to openid.
In OpenID Connect, the client is referred to as the Relying Party (RP) and the Authorization Server is known as the OpenID Provider (OP). The core specification for OpenID Connect can be found online at http://openid.net/specs/openid-connect-core-1_0.html
Figure 3: Conceptual view of OpenID Connect