Skip to main content

Authorization Code grant type with WSO2 API Cloud

Instead of requesting the authorization straight from the resource owner (resource owner's credentials), in this grant type, the client directs the resource owner to an authorization server. The authorization server works as an intermediary between the client and resource owner to issues an authorization code. After obtaining this authorization code then the client can call the token endpoint. The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner granted or denied the client's access request. After which the client can call the /token endpoint and request an access token. [1]

 Tutorial 

Let's see how we can demonstrate this scenario using a sample application.

1. For this I will be using the oauth2 playground application. You can setup the application as instructed in thisdoc [2] or you can download the war file from here.

2. Once you have set up this sample application let's log into API Cloud and go to your store. If you don't have any existant APIs created you can create a simple API following my previous blog post [3] 

3. Once you click on an API in the store you will be taken to a page where you need to subscribe to an API using an application. Let's create a new application in this case. Choose the 'New Application' option in the dropdown.


4. When creating the application you can specify a desired name but we need to specify the callback url for this use case to work. This callback url which you will see as an option in the configuration is a redirection URI in the client application which is used by the authorization server to send the client's user-agent (usually web browser) back after granting access. Specify the callback url as http://localhost:8080/playground2/oauth2client since we willl be using this application as our sample client. Then add the application.

5. After this step you will be directed back to where you need to subscribe with this application. Select the newly created application and subscribe to it.



6. The above step will redirect you to the subscriptions page. Generate keys for this created application. We will need the client id and client secret for the rest of the steps so you will need to copy these values.


7. Assuming that you have started the TOMCAT server access the sample application using this url [4] and click on the 'import photos' icon. In the UI that appears enter the following details and select Authorize.

 Authorization Grant Type : Authorization Code

 Client ID : (you need to copy this client id from the generated keys above. You need to copy the consumer key value here.)

 Scope : Production

 Callback URL : http://localhost:8080/playground2/oauth2client

 Authorize Endpoint : https://api.cloud.wso2.com:8243/authorize


8. Next you will get another screen to enter your credentials, specify the full username which appears on the right top hand corner of the API store UI. ex:shenavidemel@gmail.com@mydemo.
Login and then approve/approve always in the next screen.

At this step the client directs the user-agent to make the following HTTP request using TLS.

 GET /authorize?response_type=code&client_id=<client_id>&scope=PRODUCTION&redirect_uri=%20http%3A%2F%2Flocalhost%3A8080%2Fplayground2%2Foauth2client HTTP/1.1 Host:api.cloud.wso2.com Content-Type:application/x-www-form-urlencoded

 9. After this the authorization server redirects the user-agent by sending the following HTTP response and this authorization code will be displayed in the next UI which appears.

 HTTP 1.1, 302 Found Location: http://localhost:8080/playground2/oauth2client?code=<authorization_code>

10. Provide the details below to get the access token, notice that you will be receiving the authorization code mentioned in above in this UI.

 Callback URL: http://localhost:8080/playground2/oauth2client
Access Token Endpoint: https://gateway.api.cloud.wso2.com:8243/token
Client Secret: (client secret received at the application registration in the API cloud in above step


In order to get the access token our client application will be making a request to the token endpoint of the API cloud with the authorization code received from above which will generate the access token for us. See the request that gets sent to the token endpoint below.

POST /token HTTP/1.1 Host:gateway.api.cloud.wso2.com

Authorization: Basic base64<client id : client secret>

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=%20http%3A%2F%2Flocalhost%3A8080%2Fplayground2%2Foauth2client
11. Now that you have received your access token. You can provide this token and invoke the API which you created in the API Cloud successfully.

curl -k -X GET --header 'Accept: text/xml' --header 'Authorization: Bearer <access_token_received_above>' 'https://gateway.api.cloud.wso2.com/t/mydemo/phoneverify/1.0.0/CheckPhoneNumber?PhoneNumber=123456&LicenseKey=0'

Now we have successfully used the authorization code grant type to generate and access token in the API Cloud


References:

[1] https://docs.wso2.com/pages/viewpage.action?pageId=45951037
[2] https://docs.wso2.com/display/IS510/Setting+Up+the+Sample+Webapp
[3] http://shenavid.blogspot.com/2015/10/creating-api-using-swagger.html
[4] http://localhost:8080/playground2/
[5] https://docs.wso2.com/display/IS510/Authorization+Code+Grant
[6] https://docs.wso2.com/display/AM1100/Generating+Access+Tokens+with+Authorization+Code+-+Authorization+Code+Grant+Type









Comments

  1. dilhashaFebruary 7, 2019 at 4:09 AM

    Thanks for this very detailed post. It was really helpful. :)

    ReplyDelete

Post a Comment

Popular posts from this blog

Processing large payloads with the esb script mediator iteratively

Overview WSO2 ESB uses Rhino engine to execute JavaScripts. Rhino engine converts the script to a method inside a Java class. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters, since the Script mediator converts the payload into a Java object. However, you can use the following alternative options to process large JSON data volumes. The script mediator which is used in ESB is powered by the Rhino engine. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters which is a limitation in the script mediator being used in the esb versions less than 5.0.0. In ESB 5.0.0 there is a higher capability to process larger payloads using script mediator. In order to process such large payloads we can follow the below two approaches. 1. Replace the javascript tranformation logic using java code by writing a custom mediator. [1] 2. Break down the large payload and execute them as sections using ...
Post a Comment
Read more

Invoking external endpoints using the call mediator in wso2 api manager

Introduction In API Manager if you need to do any service chaining use cases the call mediator comes in handy. If you need to use the response received by invoking one endpoint and then use it to invoke another endpoint you can use the call mediator in API Manager. The call mediator behaves in a synchronous manner. Hence, mediation pauses after the service invocation and resumes from the next mediator in the sequence when the response is received. You can read more about the call mediator in the wso2 esb documentation [1] . In api manager 1.10.0 the call mediator works in the blocking mode. Prerequisite Before we can use the call mediator in API Manager 1.10.0 we need to make the following changes to some configs. We need to comment the jms transport sender in axis2_blocking_client.xml found in the location APIM_HOME/repository/conf/axis2. This will resolve the jms sender initialization issues.   <!--transportSender name="jms"        ...
1 comment
Read more

Configure WSO2 Identity Server for single sign on with Moodle - Part I

Introduction Moodle is a learning platform designed to provide educators, administrators and learners with a single robust, secure and integrated system to create personalized learning environments.[1]. This is commonly used in the education sector and there might be occurrences where it would require to use SAML to login to Moodle instead of the default basic authentication. For this we would need to have an Identity Provider capable of issuing such SAML tokens and Moodle configured to accept the tokens in order to do the authentication I will be discussing this in two parts. Part I - How to configure moodle for SSO with WSO2 Identity Server Part II - How to carry our user provisioning and attribute profile mapping with Moodle and WSO2 Identity Server Let's see how this can be achieved using a SAML authentication plugin provided by one login. Prerequisite  You need to have a working version of Moodle installed. If you want to try this tutorial from scratch you can ...
1 comment
Read more