OAuth 2 Implicit Grant Type Flow Example

In this tutorial, you will learn how to use an OAuth 2 Implicit Grant Type authorization flow to acquire an access token from an authorization server.

The Implicit Grant Type was previously recommended for native apps and JavaScript apps where the access token was returned immediately without an extra authorization code exchange step. When following an Implicit Grant flow a client application will receive access token right away and because exposing an access token to a client application this way is insecure, the current OAuth 2 best practices, discourage us to use an implicit grant flow and suggest that we use an Authorization Code Grant flow instead.

Implicit Grant – Request

Below is a cURL example of how to create a request URL to acquire an access token using the Implicit Grant type.

curl --location --request GET 'http://localhost:8080/auth/realms/appsdeveloperblog/protocol/openid-connect/auth?response_type=token&client_id=photo-app-client&state=4hfu822jfot3vsfw62k&redirect_uri=http://localhost:8082/callback&scope=profile'

Where:

• http://localhost:8080/auth/realms/appsdeveloperblog/protocol/openid-connect/auth – is a request URL to a local standalone Keyclock authorization server running on my computer. It could be a URL to any other OAuth authorization server. It does not need to be Keyclock. If you are interested to learn how to download and install Keyclock, have a look at my Keyclock tutorials,
• response_type – REQUIRED. This request parameter is required and its value MUST be set to “token”,
• client_id – REQUIRED. This is an OAuth client identifier. A client application that communicates with an authorization server needs to first register itself with that authorization server and acquire a client_id and a client_secret. For this request to work, providing client_id is sufficient,
• redirect_uri – OPTIONAL. This value is a URL to a page in your application that will handle the response from an authorization server. If this request is valid and is successful, an authorization server will generate an access token and it will redirect the user to a URI provided in this request parameter. The access token will be attached to this redirect URI as a query string parameter. If the request_uri is included in the request, its value must much the request URI value registered with an authorization server. Otherwise, the request will not be successful.
• state –  RECOMMENDED. This is an opaque value used by the client to maintain state between the request and callback. Your client application will need to generate this random alphanumeric string of characters and include it in the request. The authorization server will attach this value to a redirect_uri as a query string parameter. This “state” parameter SHOULD be used for preventing cross-site request forgery. The page that handles the response from the authorization server will need to read this value and compare it to the original one that was sent with an initial request. The two values must match,
• scope – OPTIONAL. The scope of the access request. This value will be different for your application depending on the scopes you have configured in the authorization server.

Implicit Grant – Response

If the request for an access token is successful, then the authorization server will issue an access token and will redirect the application to the URL specified in the redirect_uri request parameter. The access token will be attached to a redirect URI. Below is an example of how the redirect will look like.

http://localhost:8082/callback
#state=4hfu822jfot3vsfw62k
&session_state=7f86f0c8-b7e8-47cb-ba9c-62e846789e3d
&access_token=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICItNUlsX2I0cUktdWFvaEI3d244UHY3WEM2UEktU3BNbmZCRnlJZUx6QTJNIn0.eyJleHAiOjE1OTMwMTkyNzIsImlhdCI6MTU5MzAxODM3MiwiYXV0aF90aW1lIjoxNTkzMDE4MzcyLCJqdGkiOiJhNzVlYmU1OS0xY2Y2LTQyYjMtYjI5ZS05MTJmOGJlMTk5OWMiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvYXBwc2RldmVsb3BlcmJsb2ciLCJzdWIiOiIxZGRlM2ZjMy1jNmRiLTQ5ZmItOWIzZC03OTY0YzVjMDY4N2EiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwaG90by1hcHAtY2xpZW50Iiwic2Vzc2lvbl9zdGF0ZSI6IjdmODZmMGM4LWI3ZTgtNDdjYi1iYTljLTYyZTg0Njc4OWUzZCIsImFjciI6IjEiLCJzY29wZSI6InByb2ZpbGUiLCJuYW1lIjoiS2FyZ29wb2xvdiIsInByZWZlcnJlZF91c2VybmFtZSI6InNlcmdleSIsImZhbWlseV9uYW1lIjoiS2FyZ29wb2xvdiJ9.UfhvTGFLT1yD2Ao-158dzrlimKCJWOD0XdGT1zd-QbD9HpC0_11nmULp4Smy8J4gV9WTd7hNnxKwAcpjEx2LbYDpE1xQ58pLbdKLHmOkkoj5N71mz78axHTAv_1aRD3L6PaILDaifD5P_j7FQbx4E-w1TyxNouw5ktr611QaXanexTmj9zsnsZRHhsI8hYuPEbnepQRUF6MxNWRzKOI82V34BH-peRRulJQGI5rKpGFTWk38_F2pBSdtAfGF9tOHc8feaqKCx5hXFaKn4rZ_Pwxxhzb5v7RCwK9jxY2BEc0gjPHhjWVrR8iN2gX1LPOOVxFDeQEpcnCtbx1Jf2dL9A
&token_type=bearer
&expires_in=900

Where

• http://localhost:8082/callback – Is a value provided in the redirect_uri request parameter,
• state – REQUIRED. If the “state” request parameter was present in the client request for an access token, then an authorization server must return the same value in this parameter,
• access_token – REQUIRED. This value is an access token issued by the authorization server. The value is Base64 encoded,
• token_type – REQUIRED. The type of an access token issued by the authorization server,
• expires_in – RECOMMENDED. This response parameter might be omitted depending on the authorization server you use. This value specifies the number of seconds an access token will be valid. For example, the value “3600” denotes that the access token will expire in one hour from the time the response was generated.

I hope this tutorial was helpful to you. If you would like to learn how to acquire an access token using other OAuth 2 grant types, then have a look at OAuth 2 authorization flows tutorials.

Happy learning! 🙋🏻‍♂️