We have the following scenario to cover. We need to create some rest services in Pega with OAuth 2.0 authentication and JWT Bearer. The external application will call Pega Rest services with JWT bearer in header of the request. If i am not wrong in Pega Infinity 24 version onwards it is possible to configure OAuth 2.0 Rest services in Pega with JWT Bearer grant type by configuring an OAuth 2.0 Client Registration rule.
My question is to know whether someone has already implemented in their system this use case or scenario and what are the steps to follow.
Basically we need to know whether it is possible to configure rest services in Pega with Oauth 2.0 and JWT bearer where the JWT is received from the external application in the request´s header and that JWT token must be validated against our company SSO server before the service is executed.
@IsraelU1 Set the Service Package for your Service-REST rules to Custom authentication, because the caller is already sending a JWT and Pega must validate it before running the service.
Create a custom Authentication Service and point it to an authentication Activity that runs at the start of every request.
In that Activity, read the Authorization: Bearer <JWT> header, then validate the JWT against a Token Profile configured for your company SSO validation (including signature and required claims).
Store the SSO signing keys in a keystore (JWK/JWKS material as required by your Token Profile) so the token signature can be verified reliably.
If validation passes, map the token identity to a Pega operator/access group and mark the requestor as authenticated; if it fails, throw an authentication error so the REST service never executes.
I have everything set as you propose but i do not understand pretty well what to do in the following statement:
If validation passes, map the token identity to a Pega operator/access group and mark the requestor as authenticated;
You mean that the operator id/access group or identity should come as a claim (for instance in such as preferred_username claim) in the JWT token somehow, so we can do an obj-open of a predefinied Operator ID qirh the appropiated access group associated to it that grant permissions to execute the service, am i correct?
Yes, you need a deterministic way to turn the JWT subject into a Pega requestor that has an Operator ID + Access Group so authorization can work.
you can do in the auth activity is Pick one claim as the user key (usually sub, preferred_username, or email). Look up a matching Operator ID (Obj-Open Data-Admin-Operator-ID) where pyUserIdentifier or pyOperatorID matches that claim value. If you find it, set the requestor to run as that operator (so Pega applies the operator’s Access Group/roles when the service rule runs).If you don’t find it, fail authentication (401/403) so the REST service never executes.
Thanks a lot for your quick and clear response. I will finish implementing the last part “map the token identity to a Pega operator/access group and mark the requestor as authenticated or throw an authentication error if it fails” and let you know how it went.
Just one last question. When you says in your last comments:
If you find it, set the requestor to run as that operator (so Pega applies the operator’s Access Group/roles when the service rule runs)
You mean to do this by using API Tools in a java step in the activity to set the Operator ID somehow as a requestor or in page so the service can pick it up from memory and authorize the service execution. correct?
not Java, and not “store it on a page so the service picks it up.”
You do it inside the Authentication Service’s authentication Activity using standard Pega steps: after you validate the JWT and Obj-Open the matching Data-Admin-Operator-ID, you log the requestor in as that operator (i.e., establish the authenticated requestor context). Once that’s done, Pega automatically applies that operator’s Access Group/roles when the Service-REST runs, and normal rule/security checks work. So the flow is: validate token → find operator → establish authenticated requestor as that operator → continue; if any step fails → return 401/403 and stop.