Implicit Grant
  • 19 Nov 2023
  • 4 Minutes to read
  • Dark
    Light

Implicit Grant

  • Dark
    Light

Article summary

The Implicit Grant is designed primarily for client-side applications where the token is returned directly without an intermediate authorization code. While the Authorization Code flow requires a back-end server component to protect the client secret, the Implicit flow does not. It's simpler but considered less secure than the Authorization Code Grant. Despite its convenience, it's essential to be aware of its security implications.

Request an Access Token

Clients request an access token by directing the user to the /oAuth/Authorize endpoint. In this request, the client might ask for the openid and name permissions from the user.

// Line breaks for legibility only

https://login.agilenow.io/oauth/authorize?
response_mode=fragment
&response_type=token id_token
&redirect_uri=https%3A%2F%2Facme.com%2Fcallback%2F
&client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=openid%20name
&state=1234567890
&nonce=xyzABC123

Parameters to authorize user in Implicit Grant:

ParameterRequired/OptionalDescription
response_modeOptionalfragment provides the token directly in the URL fragment of the redirect_uri. Default value is fragment.
response_typeRequiredMust be set to token or token id_token for the Implicit Grant flow.
redirect_uriRequiredDetermines where the API server redirects the user after completing the flow. The requirements are similar to those in the Authorization Code flow.
client_idRequiredThe client ID for your application. Found in the Settings Credentials page.
scopeOptionalA space-delimited list of scopes that identify the resources the application could access on the user's behalf. Default value is openid profile name.
* - gives users all her/his scopes.
stateOptionalA string value that the application uses to maintain state between the authorization request and the response from the authorization server.
nonceOptionalA value used to associate a client session with an ID token and to mitigate replay attacks.

The Implicit Grant simplifies the flow by directly returning the token, but many of the parameters have the same purpose as they do in the Authorization Code Grant. Do note that due to its security implications, the Implicit Grant does not support the code value for response_type, nor does it typically use or return a refresh_token.

Upon successful authentication, the Agile.Now identity platform sends the access token directly to the application using the URL specified in the redirect_uri parameter. The access token is included in the URL fragment, ensuring it's not sent to the server.

External Authentication with Azure AD or Google

Additionally, Agile.Now offers the capability to integrate with external identity providers like Azure AD or Google OAuth2. In such scenarios, the actual authentication happens through Azure AD, not directly with Agile.Now. Users will be redirected to the Azure AD login page, where they enter their credentials and authenticate.

Once authenticated with Azure AD, the user is redirected back to Agile.Now, which handles the issuance of the authorization code and continues the flow as usual. This feature allows for enhanced security and the convenience of single sign-on (SSO), leveraging the robustness of established identity providers like Azure AD.

Remember to configure the necessary settings and establish a trust relationship between Agile.Now and Azure AD to enable this integration and ensure a seamless authentication experience for the users.

Successful Response

A successful response using response_mode=fragment looks like:

HTTP/1.1 302 Found
Location: https://acme.com/callback#access_token=eyJ0eXAiOi...&token_type=Bearer&expires_in=3600&state=1234567890&nonce=xyzABC123

Service returns parameters to authorize user in Implicit Grant:

ParameterDescription
access_tokenThe access token which the application will use to make requests on behalf of the user.
token_typeSpecifies the type of token returned. Typically this is Bearer.
expires_inRepresents the lifetime of the access token in seconds.
scopeA space-delimited list of scopes for which the access token is valid. This could reflect the requested scopes or the granted scopes by the server.
stateIf a state parameter was included in the request, the same value should appear in the response. This helps the client app confirm the response was not tampered with.
id_token(If requested) A JWT that contains claims about the authentication of the end-user.
errorAn error code string returned if there's an error in the authorization process.
error_descriptionA human-readable UTF-8 encoded text providing additional information, used to assist the client developer in understanding the error that occurred.

The Implicit Grant flow returns the access token directly in the URI, rather than an authorization code. The app can then extract this token from the URI and use it to access the user's data. As always, it's important to ensure the security of the application when using this flow, as the token can be exposed to the resource owner or other entities with access to the resource owner's user-agent.

Error Response

Error responses are also sent to the redirect_uri, allowing the app to handle them:

HTTP/1.1 302 Found
Location: https://acme.com/callback#error=invalid_request&error_description=Client%20authentication%20failed.&state=1234567890

Use a Token

With the Implicit Grant, you directly obtain the access token without an intermediate code exchange step. Use this token to make requests to the desired resource. Note that the Implicit flow doesn't typically return a refresh token due to its less secure nature. When the token expires, you would need to initiate the flow again to obtain a new token.

In summary, while the Implicit Grant provides a quicker way to get an access token, especially for client-side apps, it has security considerations. Developers are encouraged to consider other flows like Authorization Code with PKCE for better security, especially for newer implementations.


Was this article helpful?