- 19 Nov 2023
- 4 Minutes to read
- Print
- DarkLight
Implicit Grant
- Updated on 19 Nov 2023
- 4 Minutes to read
- Print
- DarkLight
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:
Parameter | Required/Optional | Description |
---|---|---|
response_mode | Optional | fragment provides the token directly in the URL fragment of the redirect_uri . Default value is fragment . |
response_type | Required | Must be set to token or token id_token for the Implicit Grant flow. |
redirect_uri | Required | Determines where the API server redirects the user after completing the flow. The requirements are similar to those in the Authorization Code flow. |
client_id | Required | The client ID for your application. Found in the Settings Credentials page. |
scope | Optional | A 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. |
state | Optional | A string value that the application uses to maintain state between the authorization request and the response from the authorization server. |
nonce | Optional | A 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:
Parameter | Description |
---|---|
access_token | The access token which the application will use to make requests on behalf of the user. |
token_type | Specifies the type of token returned. Typically this is Bearer . |
expires_in | Represents the lifetime of the access token in seconds. |
scope | A 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. |
state | If 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. |
error | An error code string returned if there's an error in the authorization process. |
error_description | A 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.