@SayakB

Pega currently connects to Oracle using standard JDBC with database user/password or network-level security, not OAuth tokens from Azure Entra, so direct DB authentication via OAuth is not supported out of the box. In this setup, OAuth/Entra is normally used for app-level access (users, services), while the DB still uses a technical account managed by the DB team. For production stability, you should avoid tying DB connectivity to a short-lived 1-hour token and instead use managed identities / key vault + DB credentials, so your Pega pods always have a valid way to connect. Token-based flows are better used between Pega and REST/HTTP services, not for core DB connectivity. At container or pod startup, Pega just needs the JDBC URL and credentials; token retrieval and rotation should stay outside Pega (for example, handled by Azure infrastructure and injected via secrets). A common approach is: Azure Entra secures access to Key Vault, Key Vault stores DB password, and Kubernetes injects it as a secret to Pega, keeping latency low while still being secure. In short, use OAuth/Entra around the infrastructure and secrets, but keep the DB connection itself as a regular JDBC connection supported by Pega.