Skip Navigation

Implicit grant

The implicit grant type is optimized for browser-based applications. The implicit grant type is used for user authentication-only (both server-side and JavaScript applications), or for authentication and access token requests (JavaScript applications). In the implicit flow, all tokens are transmitted through the browser. Advanced features such because refresh tokens are not allowed as the security of the tokens cannot be guaranteed.
The implicit grant flow has the following steps:
  1. Your application directs the browser to the authentication server sign-in page, where the user authenticates.
  2. The authentication server redirects the browser to the specified redirect URI, and includes the access and ID tokens as a hash fragment in the URI.
  3. Your application extracts the tokens from the URI.
  4. Your application can now use these tokens to call the resource server (for example, an API) on behalf of the user.
Starting this flow is very similar to the authorization code flow except that the 
response_type
 is 
token 
or 
id_token
 instead of 
code
.
Step 1: Your browser makes a request to authorize the endpoint of the authorization server.
GET https://<server>/AuthServices/Auth/connect/authorize? response_type=token &client_id=<client_id> &redirect_uri=<your_app_callback_url> &scope=openid profile athoc.iws.web.api offline_access &state=<guid> &acr_values=tenant:<org_code>
Step 2: The user logs in.
If the user does not have an existing session, this will open the authentication server sign-in page. After authenticating, or if the user has an existing session, the user arrives at the specified 
redirect_uri 
with a token as a hash fragment.
 
Step 3: The authentication server sends a redirect response.
 
https://localhost:8080/# access_token=eyJhkjughfs... &token_type=Bearer&expires_in=3600 &scope=openid &state=<state>
Your application must now extract the tokens from the URI and store them.