For Question 1:
While using OIDC claims (ad_groups) for model operator & access groups, the key point is you can drive operator provisioning from OIDC claims, but you shouldn’t rely on D_pzSSOAttributes during provisioning. Instead, you use one of the below
- direct claim mapping with the curly‑brace syntax in the provisioning data transform, or
- a requestor‑scope data page invoked in that data transform that reads the claims.
During OIDC authentication pega validates the ID token and exposes claims for mapping in the Auth Service configuration. In operator provisioning, you can reference those mapped claims directly in the “Enable operator provisioning using model operator” configuration
- via expression (for the Model operator field) or
- via data transform (Class Name = Data-Admin-Operator-ID).
The supported way to read claims in a provisioning data transform is to use the curly‑brace notation:
OperatorID.pyAccessGroupsAdditional = {ad_groups}
OperatorID.pyAccessGroup = {ad_groups[0]}
OperatorID.pyOrganization = {org}
OperatorID.pyUserIdentifier = {sub}
You can then take {ad_groups}, apply your own precedence rule (e.g. pick first matching group from an allowed list), derive a Pega access group or model operator ID from that and set .pyAccessGroup, .pyAccessGroupsAdditional, or even the model operator name. If you need more complex logic (mapping multiple AD groups to different model operators) then define a requestor‑scope data page whose source is a data transform or activity, inside that, read the OIDC claims via {claimName} or by looking at your mapping, then have your data transform compute the model operator and access groups.
For first‑time provisioning, you use the operator provisioning data transform to pick the model operator based on {ad_groups}, set .pyAccessGroup and .pyAccessGroupsAdditional accordingly. For subsequent logins, you use a Post‑Authentication Activity to re‑read the claims, adjust access groups if the user’s AD group membership changed (for example, remove/add access groups based on current {ad_groups}).
So, yes there is a supported way to access OIDC claims during provisioning and it is to use the claim‑reference syntax ({claimName} and, for arrays, {ad_groups[0]}) inside the provisioning data transform or expression, rather than relying on D_pzSSOAttributes being populated at that exact moment.
And for Access/ Refresh tokens, for OIDC, the access token is persisted as an instance of Data-Admin-Security-OAuth2-AccessToken (and related token key classes) and stored in PR_DATA_TOKEN (and related tables). You can see this in the DB and through classes such as Data-Admin-Security-AccessTokenKeys. Pega also exposes the Access Token to the clipboard during authentication via internal APIs, which you can reach from a Post‑Authentication Activity. In Post-Authentication Activity use OOTB activity GetOperatorAccessToken or similar
to retrieve the current Access Token for the authenticated operator.
For Question 2:
And for Refresh token, there is no straight OOTB way.
Pega handles token refresh for its own OAuth clients, but retrieving the raw Refresh Token from an external IdP and using it directly inside Pega is not fully exposed, and several posts point out that refresh handling may need custom logic or separate calls to the IdP
So for downstream REST calls on behalf of the user, use the Access Token you can retrieve via Post‑Authentication Activity and token management classes/activities. Have a strategy to refresh or re‑obtain tokens if they expire either by calling the IdP’s token endpoint (custom logic) or by using Pega’s token revocation/renewal patterns (pxRevokeToken + new OAuth request).