Implicit Flow
You would use this method if your OAuth client was a web application written in JavaScript code which runs in the browser, rather than on a server. In this case, the client app cannot be reliably authenticated (because the client credentials would be accessible to the resource owner and other applications running on the same device as the client). Like the Authorization Code Flow, it too relies on a browser.
-
The client initiates the flow by directing the user's browser to the authorization endpoint, adding querystrings to the URI as follows:
Table 2: Implicit Flow querystrings Querystring Description 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. - Cloud Access Manager authenticates the user (using the browser) and establishes whether the user grants or denies the client's access request.
-
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.
http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600
- The browser follows the redirection instructions by making a request to the web-hosted client resource (which does not include the fragment). The browser retains the fragment information locally.
- The web-hosted client resource returns a web page (typically an HTML document with an embedded script) capable of accessing the full redirection URI including the fragment retained by the browser, and extracting the access token (and other parameters) contained in the fragment.
- The browser executes the script provided by the web-hosted client resource locally, which extracts the access token.
- The browser passes the access token to the client. The access token can then be used to access the required resource.
Approval
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.
OAuth v2.0 client types
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.
public
Applications which run in an environment in which the confidentiality of client credentials cannot reliably be protected. Generally, this would include JavaScript applications which execute in the browser, and native applications which run on the end-user’s device. For public client types, Cloud Access Manager does not authenticate the client.
confidential
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.
What is OpenID Connect?
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
