OAuth 2.0 – Part 3 – Pega as OAuth client – Authorization Code grant type

This is the third blog article of the OAuth series. For a better understanding, I would suggest you to visit the previous blog articles on OAuth 2.0 in order – Part 1 & Part 2.

https://myknowtech.com/tag/oauth

In this blog article, we will see how Pega can act as OAuth client for authorization code grant type. I will be using LinkedIn as OAuth provider for authorization code

The article was created using earlier Pega 8 version! but the core concept remains the same! Use this blog article to learn the concepts and you can try the entire tutorial in the latest versions as well.

What is the authorization code grant type?

This is mainly used when the OAuth client is an individual user and not an application.

It involves three rounds of API calls

1. Get authorization code
2. Get access token using the code
3. Access the protected resource using access token.

the authorization server acts as an intermediator between the client and the resource owner. How?

We saw the Facebook example in the Understanding blog article. When we tried to signup Pinterest using Facebook login, Facebook (authorization server) provided us with a login screen. The user should validate the credentials manually against Facebook authorization server which is not stored in client applications thus providing a security benefit that the resource owner credentials are never shared with the client.

This process flow can be of same as the standard OAuth flow diagram above.

(1) The client requests the authorization from the resource owner. The authorization request can contain details that can identify the client (for example, client ID)

(2) The client receives the authorization code from the server.

(3) The client sends another request presenting the grant type (authorization code) to the authorization server.

(4) The authorization server validates the request and returns the client with the access token.

(5) Now with the token as an authentication parameter, the client sends the request to the resource server to access the protected resources (for example, Facebook pictures)

(6) With the right authorization the resource server responds with the resources.

So yeah 3 API calls and the first two API calls to get the access token will be done by Pega OAuth engine (the standard engine APIs)

Let’s start. Here I am gonna use LinkedIn as OAuth provider.

How to create a new app in LinkedIn developer console?

Step 1: Launch the LinkedIn developer URL – https://www.linkedin.com/developers/

Step 2: If you don’t have a developer account, create one first.

Note: You also need a company page to use for this tutorial!!

Step 3: You can start creating a new app. The steps are exactly similar to how we created an app in Twitter.

Step 4: Once created, you can find all your apps under My Apps.

Step 5: Verify the credentials in the Auth tab.

You will see the client credentials along with the default permissions. These permissions are mandatory for LinkedIn to get the access token. Permission serves as scope for your api calls.

3-legged permission refers to an authorization code which involves 3 API calls.

We will have a simple requirement to get the current user profile details in LinkedIn

https://api.linkedin.com/v2/me

You can find the API documentation

https://docs.microsoft.com/en-us/linkedin/shared/integrations/people/profile-api?context=linkedin/consumer/context

As we saw in the previous post, two main rules are involved in achieving OAuth client authentication in Pega.

a) OAuth 2.0 provider

b) Authentication profile to be used in the connectors.

Like shipped twitter OAuth provider instance we have once for LinkedIn as well

Records -> Security -> OAuth 2.0 providers

Click and open the LinkedIn instance

We will create a new authentication profile on the fly using REST wizard.

Step 1: Start the connect REST wizard

Designer studio -> Integration -> Connectors -> Create REST Integration – start the wizard

Step 2: Define OAuth authentication

Choose LinkedIn, Authorization code grant type. Provide the client credentials for the linkedIn app.

Specify the scope – permissions with space separation

Redirect URL endpoint – Pega fills this automatically. Redirect URI should be there for authorization code grant type. Because here for the first time, the user has to manually approve the access and thus LinkedIn will redirect back to Pega with the authorization code.

You see the auto-filled URL corresponds to a service-REST rule under OAuth2 service package

You can explore these service activities on your own 😉

Step 3: Grant authorization.

During the wizard step, you have an option to grant authorization. Click on the connect button.

You will see a pop-up with the LinkedIn login screen.

Enter your credentials and click sign in. You will get a disconnect option, if everything is successful.

So, what happened at the backend?

In the previous post, we saw the corresponding engine API to get the access token.

First, go to App explorer and open the instances of class Data-Admin-Security-OAuth2-AuthorizationCode

Click and open the instance and view the XML content.

Authorization code are associated with the auth profile and operator ID.  There are few engine API corresponding to authorization code grant type.

Again, getting back to the wizard click next.

Step 4: Use the GET method.

Step 5: Specify the data model using Add a response option

You see a successful response on run.

Step 6: Complete the wizard to generate the rules.

Step 7: Open the newly created data page and run and test the rule.

You will see a new access token instance created for our LinkedIn profile.

App explorer – > Data-Admin-Security-OAuth2-AccessToken click to open the instances

Step 8: Open the newly created access token instance and view the XML content.

You note a new value pyExpiresAt with +60 days. So LinkedIn has default expiry date for access token as +60 days. Till then all requests can be done using the same access token unless revoked manually!!

There is one more interesting UI component corresponding to OAuth authorization code grant type.

Step 1: Open any available section for testing.

Step 2: Drag and drop the information mashup component into the section.

Step 3: click on the settings icon and configure the authentication profile as parameter for the mashup component.

Save the section

Step 4: Now open the section from the user portal.

You see only the disconnect button. It says that already we have the access token from the OAuth provider.

Now click disconnect and check the access token instance.

You will see the LinkedIn access token is deleted from the system.

Click connect again and check the access token invocation!

Once we receive the access token, unlimited API calls can be made to the resource owner with same access token until it expires. Pega manages everything internally. All you need to do is use OAuth authentication profile in your connectors 😊

Hope you got the basics about OAuth authentication using authorization code grant type.

Ending the post here. In the next blog article, we will see how Pega can act as OAuth provider.