Implicit Grant

This example shows how to obtain an ID token and an access token. It adds notes on how to obtain the ID token only, as well.

The procedure assumes the following configuration:

For more information, see Dynamic Client Registration.

Perform the steps in this procedure to obtain an ID token and an access token using the Implicit grant:

1. The client makes a GET call to AM's authorization endpoint specifying, at least, the following parameters:

   • client_id=your_client_id

   • response_type=token id_token

     To obtain only an ID token, use response_type=id_token instead.

   • redirect_uri=your_redirect_uri

   • nonce=your_nonce

   • scope=openid profile

   For information about the parameters supported by the /oauth2/authorize endpoint, see "/oauth2/authorize".

   If the OAuth 2.0/OpenID provider is configured for a subrealm rather than the Top Level Realm, you must specify it in the endpoint. For example, if the OAuth 2.0/OpenID provider is configured for the /alpha realm, then use /oauth2/realms/root/realms/alpha/authorize.

   For example:

   https://openam.example.com:8443/openam/oauth2/realms/root/realms/alpha/authorize \
   ?client_id=myClient \
   &response_type=token%20id_token \
   &scope=openid%20profile \
   &redirect_uri=https://www.example.com:443/callback \
   &state=abc123 \
   &nonce=123abc

   Note that the URL is split for readability purposes and that the state parameter has been included to protect against CSRF attacks.

2. The end user logs in to AM, for example, using the credentials of the demo user. In this case, they log in using the default chain or tree configured for the realm.

   After logging in, AM presents the AM user interface consent screen:

   Consent Screen

   
   
   

   Note that requesting the profile scope translates into requesting access to several claims. For more information about the special profile scope, see About Claims.

3. The end user selects the Allow button to grant consent for the profile scope.

   AM redirects the resource owner to the URL specified in the redirect_uri parameter.

4. Inspect the URL in the browser. It contains an access_token and an id_token parameter with the tokens AM has issued. For example:

   https://www.example.com:443/callback/#access_token=pRbNamsGPv1T7NfAf5Dbx4AHM2c&id_token=eyJ0eXAiOiJKV1QiLCJra...7r8soMCk8A7QdQpg&state=123&token_type=Bearer&expires_in=3599

   If you only request an ID token, the response would not include the access_token parameter.

5. (Optional) The relying party can request additional claims about the end user from AM.

   For more information, see "/oauth2/userinfo".

This example shows how to obtain an ID token and an access token. It adds notes on how to obtain the ID token only, as well.

The procedure assumes the following configuration:

For more information, see Dynamic Client Registration.

Perform the steps in this procedure to obtain an ID token and an access token using the Implicit grant:

1. The end user authenticates to AM, for example, using the credentials of the demo user. For example:

   $ curl \
   --request POST \
   --header "Content-Type: application/json" \
   --header "X-OpenAM-Username: demo" \
   --header "X-OpenAM-Password: Ch4ng31t" \
   --header "Accept-API-Version: resource=2.0, protocol=1.0" \
   'https://openam.example.com:8443/openam/json/realms/root/realms/alpha/authenticate'
   {
       "tokenId":"AQIC5wM...TU3OQ*",
       "successUrl":"/openam/console",
       "realm":"/alpha"
   }

2. The client makes a POST call to the AM's authorization endpoint, specifying the SSO token of the demo in a cookie and, at least, the following parameters:

   • client_id=your_client_id

   • response_type=token id_token

     To obtain only an ID token, use response_type=id_token instead.

   • redirect_uri=your_redirect_uri

   • nonce=your_nonce

   • scope=openid profile

   • decision=allow

   • csrf=demo_user_SSO_token

   For information about the parameters supported by the /oauth2/authorize endpoint, see "/oauth2/authorize".

   If the OAuth 2.0/OpenID provider is configured for a subrealm rather than the Top Level Realm, you must specify it in the endpoint. For example, if the OAuth 2.0/OpenID provider is configured for the /alpha realm, then use /oauth2/realms/root/realms/alpha/authorize.

   For example:

   curl --dump-header - \
   --Cookie "iPlanetDirectoryPro=AQIC5wM...TU3OQ*" \
   --request POST \
   --data "client_id=myClient" \
   --data "response_type=token id_token" \
   --data "scope=openid profile" \
   --data "state=123abc" \
   --data "nonce=abc123" \
   --data "decision=allow" \
   --data "csrf=AQIC5wM...TU3OQ*" \
   --data "redirect_uri=https://www.example.com:443/callback" \
   "https://openam.example.com:8443/openam/oauth2/realms/root/realms/alpha/authorize"

   Note that the state parameter has been included to protect against CSRF attacks.

   If the authorization server is able to authenticate the user, it returns an HTTP 302 response with the access and ID tokens appended to the redirection URI:

   HTTP/1.1 302 Found
   Server: Apache-Coyote/1.1
   X-Frame-Options: SAMEORIGIN
   Pragma: no-cache
   Cache-Control: no-store
   Date: Mon, 04 Mar 2019 16:56:46 GMT
   Accept-Ranges: bytes
   Location: https://www.example.com:443/callback#access_token=az91IvnIQ-uP3Eqw5QqaXXY_DCo&id_token=eyJ0eXAiOiJKV1QiLCJra...7r8soMCk8A7QdQpg&state=123abc&token_type=Bearer&expires_in=3599
   Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
   Content-Length: 0

   If you only request an ID token, the response would not include the access_token parameter.

3. (Optional) The relying party can request additional claims about the end user from AM.

   For more information, see "/oauth2/userinfo".