Page Comparison

Implicit grant type is recommended to use to obtain access tokens if your application (client) is a mobile application or a browser based app such as a JavaScript client. Like in Authorization code Grant, implicit Grant type is also based in redirection flow but the redirection URI includes the access token in the URI fragment. Because of that, the client application is capable of interacting with the resource owner user agent to obtain the access token from the redirection URI which is sent from the authorization server.

The implicit grant type does not require client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. The resource owner needs to authenticate with the authorization server to obtain the access token. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing in the same device.

The diagram below depicts the flow of Implicit Grant.

The client requests for the access token with the client ID and grant type with optional parameters.
Since the resource owner authenticates directly with the authorization server, his/her credentials will not be shared with the client.
The Authorization Server sends the Access token in URI fragment to the client.
Client extract the token from the fragment and send the API request to the Resource Server with the access token.

Note
With this grant, the refresh token will not be issued for the client as the client type is public. Also note that, the implicit grant does not include client authentication because it does not make use of client secret.

Invoking the Token API to generate tokens

In his example we are using WSO2 Playground hosted as a web application to obtain the access token with implicit grant.

Setup WSO2 Playground sample webapp in a Application server. You can use WSO2 Identity Server

and setup the application following Setting Up the Sample Webapp.Login to WSO2 API Manager store and create an application as below

to host the web application following below steps.

Excerpt

You can check out the repository of the OAuth 2.0 sample from GitHub. Follow the instructions here tocheckout the folder. We refer <SAMPLE_HOME> as the modules/samples folder inside the folder where the product-is repository is checked out.

Open a terminal window and add the following entry to the /etc/hosts file of your machine to configure the hostname.

Info

title	Why is this step needed?

Some browsers do not allow you to create cookies for a naked hostname, such as localhost. Cookies are required when working with SSO. Therefore, to ensure that the SSO capabilities work as expected in this tutorial, you need to configure the etc/host file as explained in this step.

The etc/host file is a read-only file. Therefore, you won't be able to edit it by opening the file via a text editor. To avoid this, edit the file using the terminal commands.
For example, use the following command if you are working on a Mac/Linux environment.

Code Block
sudo nano /etc/hosts

Code Block

language	bash

127.0.0.1		wso2is.local

In your command line, navigate to <SAMPLE_HOME>/oauth2/playground2 in the folder you checked out and build the sample using the following command. You must have Apache Maven installed to do this (see Installation Prerequisites for the appropriate version to use).
Code Block
mvn clean install
After successfully building the sample, a .war file named playground2 can be found inside the <SAMPLE_HOME>/oauth2/playground2/target folder. Deploy this sample web app on a web container. To do this, use the Apache Tomcat server.
Note
Since this sample is written based on Servlet 3.0 it needs to be deployed on Tomcat 7.x.
Use the following steps to deploy the web app in the web container:
1. Stop the Apache Tomcat server if it is already running.
2. Copy the playground2.war file to the <TOMCAT_HOME>/webapps folder.
3. Start the Apache Tomcat server.

Make sure to update param-value the following parameter in the WEB-INF/web.xml file with the serverurl of the Identity Server if required. Service URL should have the port the application is started up with. If you have started the Identity Serve with anoff set, then the matching port should be configuredhear.

Code Block
<init-param> <description>serverUrl</description> <param-name>serverUrl</param-name> <param-value>https://localhost:9443/services/</param-value> </init-param>

Info
Note that `localhost` is the server that hosts WSO2 Identity Server and `9443` is the default SSL port of it. Inorder to access the admin services you should have the values in step 5 and 6. Since playground application is accessing the admin service OAuth2TokenValidationService, you should have the correct serverUrl,username and password asdescripbed in step 5 and 6.

Update param-value of the parameters below with credentials of an admin user if required.

Code Block

<init-param>
     <description>userName</description>
     <param-name>userName</param-name>
     <param-value>admin</param-value>
</init-param>
<init-param>
     <description>password</description>
     <param-name>password</param-name>
     <param-value>admin</param-value>
</init-param>

Update the hostname in etc/hosts to wso2is.local or something similarly appropriate.
Restart Apache Tomcat and access http://wso2is.local:8080/playground2/ (assuming Tomcat is running on HTTP port 8080). You are directed to the landing page of the sample application. Click on Import Photos and the following page appears.
Image Added

Login to WSO2 API Manager Store and create an application as below.
Image Added
Go to production keys tab in the created application, Add http://localhost:8080/playground2/oauth2client as the callback URL, select implicit from the Grant Types and click Generate Keys.
Image Added
Now go to the WSO2 Playground App in http://wso2is.local:8080/playground2/.

Versions Compared

Old Version 4

New Version 5

Key

Invoking the Token API to generate tokens