This article on Securing API using OAuth Tutorial with Implicit Grant in IBM API Connect, teaches how to secure an API with OAuth 2.0 using Implicit grant. This is second article in the IBM API Connect security series. If you have not already read through the first article (where I have explained how to implement IBM API Connect Security with Basic Authentication and LDAP user registry.), please ensure to go through it as we will reuse what we have done as part of that tutorial.
If you landed over here directly, I will also recommend you to go over my previous posts on installation, setup and writing the simplest APIs in IBM API Connect. Links are below –
- Installation of IBM API Connect in personal system
- Setting up IBM API Connect for use
- Step by step tutorial on write]ing your first and simplest API in IBM API Connect
Prologue to this tutorial
In my previous blog, I have already covered how to create a basic API and publish the same to developer portal, how to create consumer app and test it same. In my other blog,I have explained how to implement security with Basic Authentication and LDAP user registry. I won’t cover any of that in the current tutorial. Instead, I will develop this POC on top of the same API that I created previously. Here in this blog, my concentration will be to show you how to implement IBM API Connect Security with OAuth 2.0 and we’ll use implicit grant.
Followings are the list of technologies used in this tutorial –
IBM API Connect 188.8.131.52 (installed in personal laptop)
https://mockable.io for back end service mocking
Online LDAP Test Server (ldap.forumsys.com:389)
Creating a Generic OAuth 2.0 provider API for Public scheme
- As I mentioned above, in this tutorial, we will implement on oAuth2.0 implicit grant. If you want to brush up through the concept of implicit grant type, please refer to my article on the same. It’ll help you to correlate.
- We will first define a generic OAuth2.0 provider for client types which can’t maintain the client secret securely. We will reuse this same provider for different grant type meant for such public scheme.
- First step in the process of configuring OAuth in IBM API Connect is to create an OAuth provider API.
- Login to the apim portal (https://apim/apim).
- From the navigation menu, click Drafts –> APIs. Click on the Add button and select OAuth2.0 Provider API.
- A new pop up window will open up for drafting the API. Populate the fields as per your choice of names etc. In my case, I have used followings –
1234Title: OAuth2 Public End Point APIName: oauth2-public-end-point-apiBase path: /secure/publicVersion: 1.0.0
- Click on Create API button.
- A new page will open up with API Design mode. Scroll to OAuth2 section.
- In this section, the first step is to choose the Client types. Depending on the implementation, you may either choose Public or Confidential.
- Public – A public scheme can be selected if an application can’t maintain the client secret securely. For example when an application is native to a computer or mobile where the secret needs to be stored on the user’s device, for example inside the source code/configuration of the application. In thes case, the client secret is not used.
- Confidential – Select this option when the client application can maintain the client secret securely. For example, when an application runs in a browser and accesses its own server to obtain OAuth access tokens. In this case, client secret is used.
- In our scenario, we will use implicit grant and it’s suitable in case when client types are Public. So, choose Public in client type field.
- Next, we will define the scopes. You can add/remove scope entries depending on your requirement. For this POC, I am going to define 3 scopes as below –
123Scope Name: email, Description: Allow access to the Customer EmailScope Name: profile, Description: Allow access to Customer profile informationScope Name: order_list, Description: Allow access to Customer order history
- In the Grants section, we will leave everything checked apart from Application. Because Application does not fall under Public scheme.
- In the Identity Extraction section, select Basic. In our case, we have already implemented Basic Authentication using LDAP user registry (in our previous tutorial); we will use the same instead of creating something else from scratch.
- In the Authentication section, make the following entries in the corresponding fields –
- Authenticate application users using:- User registry
- User registry: – “my test ldap server” (This is something we created previously)
- In the Authorization section, keep the default Authenticated
- Keep everything else AS-IS
- Click on Save icon on top right corner of the window.
Configure API Security Defintion
- Next, we will use this OAuth provider API to secure our business API.
- We have already created an API with Basic Authentication security previously. Let’s open that API from Navigation Menu –> Drafts –> APIs –> orders 1.0.0
- Scroll down to Security Definition segment. Click on the plus icon on the extreme right of Security Definition segment, select OAuth. Populate the fields like below –
- Name: OAuth Security Defintion
- Description: OAuth Security Definition for public scheme
- Flow: Implicit
- Authorization URL: The format of the Authorization URL will be like below –
1https://<hostname>/<organisation>/sb/<oauth provider api base path>/oauth2/authorize
Hence, the URL for us will be like below –
- Also create a scope named email and provide the description as “Allow access to the Customer Email“.
- Next, scroll down to Security segment. Select OAuth security definition that we created above. Un-check the basicAuthentication security definition that we used earlier.
Add oAuth provider API to Product and Publish the changed API to sandbox catalogue
- Next, we will publish the changes to the sandbox catalogue. Click on Navigation Menu –> Drafts –> Products–> orderproduct 1.0.0 (this is the product we created earlier and will re-use it here as well.)
- Scroll to the APIs segment and add the OAuth2 Public End Point API 1.0.0 that we created. This product will already have orders 1.0.0 API as we have already added it previously as part of our earlier exercise.
- Then click on the stage icon (on the left of save icon) and select the sandbox catalogue to deploy the new addition and the changes as well.
- After this, we’ll click on Navigation Menu –> Dashboard –>Sandbox–>Products Tab. On the extreme right of the row, you will notice an icon with 3 dots. Click on it and select Publish. A popup will open, again click on Publish.
- With these steps, we have successfully published the oAuth secured API. Next, we will consume this from a consumer application.
Create a new App and Subscribe to the API
- As part of this exercise, we will create a new app and leave one we created earlier unchanged.
- So, login to the developer portal (https://ibmportal/orders/sb/) –> Apps –> Create new App with following detail –
- Title: – My OAuth App
- Description:- My OAuth App
- OAuth redirect URI:- https://iteritory.com/category/miscellaneous/ (this can be any API)
- Create the application.
- Once successfully created, note the client id and client secret in safe place.
- Then, click on API Products –> orders product (1.0.0) –> Subscribe button
- A popup will open, select the above created new app and then click on the Subscribe button.
- We are all set now!
Time to Test
As we already know with the implicit grant, we will have to first obtain an access token from the OAuth server and then we’ll use the same token to hit the resource and get the service response successfully. We’ll use curl to test it out. You can use your own testing tool. Alternatively you can also try it out from developer portal.
- We have already created the authorization url above. Let’s add few query parameters as defined in the oAuth specification for implicit grant. Following is how our complete URL looks like after adding the query parameters –
It’s pretty much self explanatory. If you have any question here, drop a comment and I will answer you.
- Now that, we have the URL ready, let’s get the access token by executing following command –
1curl --request GET --url "https://datapower/orders/sb/secure/public/oauth2/authorize?response_type=token&client_id=YOUR_CLIENT_ID&redirect_uri=https://iteritory.com/category/miscellaneous/&scope=email" --header 'accept: application/json' --header 'Authorization: Basic bmV3dG9uOnBhc3N3b3Jk' --insecure -I -s| perl -n -e '/^Location: (.*)$/ && print "$1\n"'
NOTE:- If you see, I have used a perm command to scrape out the information we need here. I have referenced this perl command from here.
- The above command will give us the access token as part of URL fragment (after#) . Well this is what we will use in our next call to the actual service. Let’s take a look at the next command to hit the actual service-
12345curl --request GET \--url https://datapower/orders/sb/orders/order \--header 'accept: application/json' \--header 'authorization: Bearer YOUR_ACCESS_TOKEN_FROM_PREVIOUS_COMMAND' \--header 'x-ibm-client-id: YOUR_CLIENT_ID' --insecure
- Execute it and you will have the result like a charm!! Well, that’s it for today. 🙂