OAuth 2.0 – Part 4 – Pega as OAuth provider
In the previous articles, we saw how Pega can act as OAuth client and access the protected resources from OAuth providers like LinkedIn, Twitter etc. In this post we will see how Pega can act the other way around by taking the role of OAuth provider.
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.
For a better understanding, please visit the below blog articles in order
https://myknowtech.com/tag/oauth
We know that Pega can act as service providers with webservices (SOAP, REST other services). These are referred as Pega APIs. Usually, these APIs are bundled with service package instances and secured by means of any authentication – Basic or OAuth in the service package instance. We will see how we can secure these protected APIs using OAuth 2.0 authentication.
Please go through my previous post on the basics of OAuth authentication and grant types. In this tutorial, we will see protecting the APIs using client credentials and shared password grant type.
What is client credentials grant type?
This is often used when the protected resources are under the control of the client and the client is an application and not an individual user.
Say for example, XYZ is a banking organization that uses Pega applications across domains. There is one Pega loan application that stores all the loan details (arrear, due date ). There is another Pega customer service application that services the customers who fail to pay the loan. Now the customer service application needs to access the OAuth protected APIs from the loan application for the loan details.
This is a perfect use case for client credentials grant type. Both Pega applications belong to the same organization (under same control with little risk) and only the applications talk.
This is a widely used OAuth grant type in Pega.
There is only one action you need to do. You need to register your client application (customer service application) with the OAuth provider application (loan application). Whenever you register any client with the resource, you will be provided with a client-ID and client-secret (this is not the same as login credentials). So, with this credential, you can directly request the access token and then with the access token, you can access the protected resource
The flow for the client credentials varies a little from the standard OAuth flow.
(1) It starts with an access token request. It skips the authorization code step. The client credentials (ID and secret) are passed in the request)
(2) The authorization server validates the client and sends the access token.
(3) & (4) With the access token, the client can access the resource.
Note: In pega there is no specific servers for authorization and resource. It is all same!
Let’s directly start by protecting the API using OAuth.
How to protect the Pega API using OAuth authentication?
This involves two steps in OAuth providers
a) Create a new client registration instance for the client application
Step 1: Records -> Security -> OAuth 2.0 client registration -> New
Create and open.
Step 2: Fill out all the configuration points in the client registration data instance.
Mostly all of the main configurations are prefilled!
Types of client –
1. Public – This is applicable when you want to use the authorization code grant type ( 3-legged api authentication).
2. Confidential – use this option when the client want to access the secured resources using the client credentials.
I am going with Confidential type.
Client ID and Client secret – these are part of client credentials. You can use the buttons to either regenerate the secret and view and download to save the keys.
All the three endpoints are automatically filled are read only. You can see all these points to some REST services under the OAuth service package.
Please explore these APIs on your own 😊
Important note: I switched to https endpoint since OAuth works in conjunction with TLS. Follow my post on SSL to host your personal edition using https
Use the view & download button to save the client secret.
Important note: Once saved, you cannot view & download the client secret unless it is regenerated again!
Supported grant types –
Client credentials is default selected and we already saw about the other grant types like authorization code and password credentials.
Authorization code –
You can specify the redirect client URIs. Just like how we specified the pega redirect URI when pega acts as a client in the previous posts
Enable refresh token – It is separate concept. When it is checked, the provider sends two token – refresh token and access token. With the refresh token, you can access a new access token once it is expired.
Password credentials –
We saw about this grant type in the introduction article. By using this option, we will validate the real operator ID and password credentials. We use this option only when high level of trust is established.
But we know that Pega supported other modes of authentication like LDAP! how to manage those using this grant type?
You see on selecting the Password credentials grant type, pega defaults the identity mapping value to ‘pydefaultIdentityMappingForPasswordGrant’. This is the shipped OOTB identity mapping instance.
I am going to go much detail into the identity mapping for now.
You can look at the activity used in the identity mapping
In activity, step 1 & 2 is for the internal pega operators and 3-6 is for external operators, where you see we can call the LDAP verify credentials activity to verify the credentials!
SAML bearer and JWT bearer –
With these two grant types, the user information can be on the SAML assertion data or with the JSON Web Token claims data. We can use identity mapping to extract the information and validate to provide the access token. These two are kind of new feature, which I won’t be touching in this post!
Note: Identity mapping is a data instance that is part of security category.
Client credentials grant type – I am using the my operator ID prem.
Important note: Please do not use this user in the real time projects. Have a separate operators, access for the client application.
For this tutorial, we will test the client credentials and password credentials grant type.
Token lifetime
You can define the lifetime for all three tokens – authorization code, access token and refresh token.
We are done with registering the customer service application client.
b) Protect the service package using OAuth authentication
For testing purposes, I am going to use the API service package.
Okay done with the configurations. Let’s do the testing part.
https://localhost:8443/prweb/api/v1/nodes/75c08abad559cc44cda33fccd5ddfaf0/agents
Important note: You should use the HTTPs. OAuth works in conjunction with SSL/TLS settings
Step 1: Open Postman and hit the URL without any authentication parameters.
As expected, invalid authorization data.
Step 2: Set OAuth 2.0 authorization in Postman application
Switch to the authorization tab and select OAuth 2.0
Click on get a new access token. Provide all the client details and click request token.
Note: You can also trace open the service-REST token to see how the processing works.
You see it went well and returned an access token.
You can also try generating an access token using the password credentials grant type. Provide a valid user name and password.
You will see a new token for the same.
Step 3: Use the token to request the resource.
Using the token as authorization, hit the URL again.
You see the agent details with API status 200.
We have successfully implemented pega as OAuth provider 😊
We are at the end of OAuth series!
