The Implicit grant type is used to obtain access tokens directly from the authorization server, without the use of the authorization code or client_secret. It is designed to be used by public clients whose source code is not secured, such as applications who use JavaScript within a browser or a mobile device. This grant type does not include client authentication because the client_secret cannot be stored safely on the public client. This grant type relies on the callback URL given when the client was registered, to validate the identity of the client.

The implicit grant type flow is very similar to the authorization code grant type:


The steps are as follows:

  • A) The client redirects the user-agent (usually a browser) to the log-in page on the authorization server.
  • B) The authorization server presents the log-in page to the resource owner via the user-agent (if the resource owner is not already authenticated to the authorization server)
  • C/D) The resource owner supplies credentials to the log-in page. This establishes the identity of the resource owner (authentication).
  • E) The authorization server requests access to resource-owner data on behalf of the client.
  • F/G) The resource owner grants the client authorization to access resource-owner data.
  • H) The authorization server redirects the user-agent to the callback URL supplied by the client in the call (which must match the redirect_uri supplied when the client registered with the authorization server). The access_token is attached to the redirect as a URL parameter. The authorization server returns an access token to the client, along with an refresh token. The authorization token can now be used to request access to protected resources from the resource server.

This example uses command-line curl to emulate the interaction outlined above. This example assumes the client has been registered in API Manager, has provided a redirect_uri, and has been issued a client_id and a client_secret. It also assumes the redirect_uri is invalid (the browser will get a 404 when attempting to redirect to the redirect_uri).

The -k command line option instructs curl to ignore certificates. The -v option specifies verbose mode so we can see the response headers.

Be sure to enclose the URLs in quotation marks. Some characters within the URL are special characters in some operating systems.

A) First, the client will direct the user-agent to a URL on the WSO2 identity server (via the API Manager). The user-agent will then direct the user to the log-in page. Once you have logged in, copy the following URL (below) into a browser, replacing <client_id> and <redirect_uri> with your own client_id and redirect_uri. Your client_id and redirect_uri should have been specified when the application was created.<client_id>&redirect_uri=<redirect_uri>&scope=openid&state=myteststate

B,C,D,E,F,G) The identity server will prompt you for a user name and password vi CAS if you don't have a valid CAS session(use your netid/password). You will then receive a trust message. Select "Allow".

B,C,D,E,F,G) If you don't currently have a valid CAS session, the identity server will prompt you for a username and password (use your NetID/password to log-in). You will then receive a trust message. Select "Allow".

H) The identity server will then redirect the user-agent to the client, now with an access_token. The URL will look something like this:


The access_token can now be used to request access to protected resources.

curl -v -k -H "Authorization: Bearer access_token"