Hellow..
We recently implemented OIDC SSO authentication in Pega. We can successfully view the ID token in D_pyOIDCLoginInfo; however, the access_token and refresh_token stored in the pr_data_token table are encrypted with the {in} prefix.
Our requirement is to retrieve the plain-text OIDC access token from the active user session so it can be used by downstream Connect-REST rules. We’re currently facing both an architectural and technical challenge.
Architecture & Business Process:-
We have a single set of downstream REST APIs configured using Rule-Connect-REST. These APIs are invoked through two different user flows:
Flow 1 – External Public Customers (API-Driven)
- An external customer initiates a process through an upstream application.
- The upstream system invokes Pega APIs and passes a JWT in the
Authorizationheader. - Pega extracts the incoming JWT into a requestor-level data page.
- The same JWT is then forwarded in the
Authorization: Bearer <token>header when invoking downstream REST services throughout non browser requestor session.
Flow 2 – Internal Case Officers (OIDC SSO)
- Internal users authenticate to Pega( portals using OIDC SSO.
- While processing work in the portal, they invoke the same downstream Connect-REST rules.
- In this scenario, the downstream API must receive the authenticated user’s OIDC access token from the current Pega session.
Constraints
- OAuth Authentication Profile cannot be used on the Connect-REST rule. If an OAuth Authentication Profile is attached, Pega automatically manages the access token, which breaks Flow 1 where the inbound JWT must be propagated unchanged.
- Duplicating Connect-REST rules is not a viable option. Maintaining two identical sets of integrations solely to support different authentication mechanisms would introduce unnecessary maintenance overhead.
- I’m not sure what happens if both an OAuth Authentication Profile(for InternalUsers) is configured and the
Authorizationheader (for external) is explicitly set in the request. Which one takes precedence?
Technical Challenge
For Flow 2, we need to programmatically retrieve the authenticated user’s OIDC access token from the active session (or from the pr_data_token table) and populate a clipboard property before invoking the Connect-REST rule.
However, the access token stored in pr_data_token is encrypted using the {in} site-key format (for example, {in}qJ0w...).
We have also found that the standard Pega decryption APIs but they do not decrypt values stored in this format.