For creating a new Authentication Profile, is it possible to use the “Grant Type” of “Client_Credentials” without sending the “Client_Secret” in the “Request Body”?
Because there is an option to include the “TrustStore” and “KeyStore”, so the client_secret is not necessary.
If it cannot be ignore, can we try to delete it somehow? (client_secret becomes a required field if “Client_Credentials” is selected for the Grant_Type)
Any other suggestion if we want to use this OOTB Authentication Profile using “Client_Credentials” grant_type without Client_Secret (in the header or request body) but only Certificate?
@MichaelC16831869 not with the out-of-the-box Authentication Profile. In Pega, the keystore and truststore handle TLS and mutual TLS at the socket level, but they do not replace OAuth client authentication, so client_credentials requires a client_secret in the profile. You can choose to send the secret in the Authorization header (Basic) instead of the request body, but the secret still goes over the wire. If your authorization server supports mutual TLS client authentication without a secret, build a custom token call: create a REST connector to the token endpoint using your keystore and truststore, post the required form fields, cache the access token on a data page, and add it as a Bearer token on your business calls. If your server supports private_key_jwt client authentication and your Pega version does not expose it in the Authentication Profile, do the same custom pattern but generate the signed JWT from your keystore before the token call. You cannot delete or bypass the client_secret field in the profile when grant type is client_credentials. For governance, keep certificate rotation in a dedicated keystore record and add short token TTL with refresh logic on failure. If you must keep everything “profile based,” log an enhancement request with Pega to add mTLS or JWT-based client authentication to client_credentials.
@Sairohith Thank you so much Sairohith! It provided much in-depth understanding now. Can you also please shed me some lights on if I already “cache the access token on a data page”, how to refresh the token if I have 401 response due to the server side rollover timeline? i.e. I want to make sure the freshness of the token (or the token call) please. Thank you!
Create a node level data page D_OAuthToken that stores access_token and an expires_at timestamp computed as now plus expires_in minus a 60 second buffer.
Set the data page refresh strategy to reload when a when rule IsTokenStale returns true if current time is at or beyond expires_at.
Read the token from D_OAuthToken for every business call and send it as Bearer.
If the connector returns 401, catch it in the error flow, call Clear Data Page on D_OAuthToken, then retry the call once so the data page reloads and fetches a fresh token.
Do not loop on repeated 401s; after one retry, fail fast and surface an actionable error.
If your AS sometimes revokes tokens early, also reload when 403 invalid_token appears.
Key the data page by client_id and requested scope to avoid cross talk between apps.
Log token fetch successes and failures, and alert if refreshes exceed a threshold so you can spot server side rollovers.
Thanks again.