OAuth and OpenID Connect Settings
OAuth and OpenID Connect Settings is a page in Salesforce Setup that controls which OAuth 2.0 authorization flows your org permits and how strictly it enforces them. You reach it by entering OAuth…
Definition
OAuth and OpenID Connect Settings is a page in Salesforce Setup that controls which OAuth 2.0 authorization flows your org permits and how strictly it enforces them. You reach it by entering OAuth in the Quick Find box and selecting OAuth and OpenID Connect Settings. The page is org-wide. It sets the baseline for every connected app and external client app that authenticates against your org, so the toggles here decide whether older, riskier grant types can run at all.
The page carries four controls: Allow OAuth User-Agent Flows, Allow OAuth Username-Password Flows, Allow Authorization Code and Credentials Flows, and Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows. Salesforce treats the user-agent and username-password flows as insecure and recommends blocking them. Because Salesforce also acts as an OpenID Connect provider, the same area of Setup ties into the OpenID Connect discovery, token introspection, revocation, and dynamic client registration endpoints that external apps rely on.
What the four toggles actually do
The four flow controls on the page
The page exposes exactly four settings, and each one switches a class of OAuth behavior on or off for the whole org. Allow OAuth User-Agent Flows governs the implicit-style flow where the access token comes back in a redirect fragment. Allow OAuth Username-Password Flows governs the grant where a client sends a username and password straight to the token endpoint. Allow Authorization Code and Credentials Flows covers the web server (authorization code) flow and client credentials flow, the modern patterns most integrations use. The fourth toggle, Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows, is not a flow switch. It tightens the authorization code flow by rejecting any request that does not carry a PKCE code challenge and verifier. Salesforce guidance is plain here. Block the user-agent and username-password flows, keep authorization code and credentials available unless you genuinely do not use them, and turn on the PKCE requirement so every code-flow client proves it started the request it is finishing.
Why username-password and user-agent flows are risky
The username-password flow asks a client to collect a real Salesforce username and password and post them to the token endpoint. That defeats multi-factor authentication, leaks credentials into client code and logs, and breaks if the user has single sign-on. Salesforce blocks this flow by default in orgs created in Summer 23 or later, and it tells existing orgs to migrate off it. The user-agent flow returns the access token in the URL fragment, where it can land in browser history, referer headers, or server logs. Neither flow supports a refresh token cleanly, so clients tend to store long-lived credentials instead. The safer replacements are well established. Server-to-server jobs should use the JWT bearer flow, which signs a JSON Web Token with a certificate instead of sending a password. Interactive apps should use the authorization code flow with PKCE. When you block the old flows here, any integration still using them stops working, so audit Login History and the Connected Apps OAuth Usage report before you flip the switch.
PKCE enforcement and the authorization code flow
Proof Key for Code Exchange protects the authorization code flow from interception. The client generates a random code verifier, hashes it into a code challenge, and sends the challenge when it requests an authorization code. When it later swaps that code for tokens, it must present the original verifier. Salesforce checks that the verifier hashes to the challenge it stored. An attacker who steals the authorization code cannot redeem it without the verifier, which never leaves the legitimate client. Turning on Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows makes this mandatory. Every authorization code request that lacks a valid PKCE pair is rejected. Public clients like mobile apps and single-page apps benefit most because they cannot keep a client secret safe, but enabling it org-wide also hardens confidential clients. Before you require PKCE, confirm your connected apps and external client apps support it. Older custom integrations may need a code update to add the challenge and verifier, and they will fail authorization until they do.
Salesforce as an OpenID Connect provider
When Salesforce issues identity tokens to other applications, it acts as an OpenID Connect provider. The discovery endpoint advertises everything a client needs to configure itself. Its URL is https://MyDomainName.my.salesforce.com/.well-known/openid-configuration, and it returns a JSON document listing the authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, and issuer, among others. The document also lists the OAuth scopes your org supports, including openid, profile, email, address, phone, api, web, full, refresh_token, and offline_access. Clients read this metadata so they do not have to hardcode URLs. ID tokens are signed with RS256, and the subject type is public. Experience Cloud sites have their own discovery URL under the my.site.com domain. The settings and endpoints described here all key off your My Domain name, which is why a clean My Domain configuration is a prerequisite. If you change or deploy My Domain, the discovery URL and every issuer value move with it, so external clients pointed at the old host stop validating tokens.
Token introspection and revocation endpoints
Two standard OAuth extensions sit alongside the settings. Token introspection lets a resource server ask Salesforce whether an access token is still valid and what it represents. The introspection endpoint returns an active field plus claims like scope, username, and expiry. By default every external client app can introspect its own tokens, and an app that registered other apps through dynamic client registration can introspect their tokens too. Token revocation lets a client invalidate a token before it expires, which is how a clean logout or a compromised-token response should work. A client posts the token to the revocation endpoint and Salesforce kills it. These endpoints matter for security operations. Introspection gives a gateway a real-time yes or no on a token instead of trusting it blindly. Revocation gives you a way to cut access immediately rather than waiting for the token lifetime to lapse. Both endpoints appear in the discovery document, so clients discover them automatically once they read the well-known configuration for your My Domain.
Dynamic client registration for API gateways
Dynamic Client Registration lets external systems register connected apps with Salesforce programmatically instead of an admin creating each one by hand. It exists for federation scenarios where Salesforce protects resources behind an API gateway and many client apps need to onboard. The registration endpoint is at /services/oauth2/register. To call it, the registering app must present an initial access token in the request header, so registration is not open to anyone. An admin generates that initial access token from a connected app set up for the gateway. Salesforce caps dynamic registration at 100 connected apps per org through this endpoint. Treat the initial access token like a master key. Anyone holding it can register new OAuth clients against your org, so store it carefully and rotate it if exposed. Most orgs with a small, known set of integrations never need dynamic registration and should leave it unused. It earns its place in multi-tenant or gateway-fronted architectures where manual app creation does not scale.
Auditing and monitoring OAuth activity
Opening OAuth flows without watching them is a blind spot. Changes to the OAuth and OpenID Connect Settings page are recorded in Setup Audit Trail, so you can see who toggled a flow and when. Inbound OAuth authentications show up in Login History with the application and authentication method, which is the first place to look when you want to know which integrations still use a flow you plan to block. When Salesforce acts as an identity provider, the Identity Provider Event Log captures the OAuth and OpenID events it issues. For higher-volume environments, Event Monitoring streams login and API events to an external SIEM for retention and alerting. The practical sequence is to turn on monitoring first, run the Connected Apps OAuth Usage report to find live consumers, then tighten the flow toggles. That order means you migrate real integrations deliberately instead of discovering them when they break. Without this visibility, abuse of a permissive flow can run for a long time before anyone notices.
Harden your org-wide OAuth flow settings
Use these steps to harden the org-wide OAuth posture from the OAuth and OpenID Connect Settings page. Audit current usage before you block anything, because blocked flows stop working immediately for any integration that still relies on them.
- Open the settings page
From Setup, enter OAuth in the Quick Find box and select OAuth and OpenID Connect Settings.
- Check current usage first
Review Login History and the Connected Apps OAuth Usage report to find which integrations use the user-agent and username-password flows before you disable them.
- Block the insecure flows
Turn off Allow OAuth User-Agent Flows and Allow OAuth Username-Password Flows once you have migrated or confirmed no live integration depends on them.
- Require PKCE
Enable Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows so every authorization code request must carry a code challenge and verifier.
- Save and confirm
Save the page, then test a known integration end to end and watch Login History to confirm legitimate clients still authenticate.
Permits the redirect-fragment flow. Salesforce recommends blocking it because the token can leak into URLs and logs.
Permits clients to send a username and password to the token endpoint. Blocked by default in Summer 23 and later orgs; block it everywhere.
Permits the web server (authorization code) and client credentials flows. Keep enabled unless you do not use them.
When enabled, rejects every authorization code variation that does not implement PKCE protection.
- Blocking a flow takes effect immediately. Any integration still using it stops authenticating, so migrate before you toggle.
- Requiring PKCE breaks older clients that do not send a code challenge and verifier; update their code first.
- The username-password flow ignores multi-factor authentication and single sign-on, so it is the highest-risk toggle to leave on.
- The OpenID Connect discovery URL and issuer values are tied to your My Domain; changing My Domain moves them and can break external clients.
Prefer this walkthrough as its own page? How to OAuth and OpenID Connect Settings in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on OAuth and OpenID Connect Settings.
Hands-on resources to go deeper on OAuth and OpenID Connect Settings.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the OAuth and OpenID Connect Settings page in Setup let an admin control about scopes?
Q2. On the OAuth and OpenID Connect Settings page, what does the OpenID Connect discovery endpoint expose?
Q3. What is the default access-token lifetime that these OAuth and OpenID Connect Settings establish?
Discussion
Loading discussion…