You are here:
API (Enable OAuth Settings): Authorization Code and Credentials Flow Settings Control
This control configures the specific security requirements for the "Authorization Code and Credentials Flow".
Control Name
Connected Apps: API (Enable OAuth Settings): Authorization Code and Credentials Flow Settings
Recommended Configuration
Enable Authorization Code and Credentials Flow.
Do Not Require or Deselect Require Secret For Web Server Flow and Require Secret for Refresh Token Flow.
Control Overview
This control configures the specific security requirements for the "Authorization Code and Credentials Flow," determining whether a Client Secret must be validated based on whether the application is a "Private Client" (server-side) or a "Public Client" (browser/mobile).
Security Risk If Not Configured
Incorrectly requiring a secret for public clients forces the hard coding of credentials into front-end code where they are easily stolen, while failing to require a secret for private clients allows attackers to exchange intercepted codes without needing the application's private key.
Threat Scenarios
An attacker decompiles a mobile app to extract a hard-coded Client Secret or intercepts an authorization code from a server-side app and successfully trades it for a high-privilege access token because no secret was required for the exchange.
Estimated CVSS Score Range
Critical (9.0–10.0).
Risk Impact Considerations
Misconfiguration leads to either the compromise of client credentials or the enablement of unauthorized session hijacking, both of which result in persistent, unauthenticated access to sensitive data.
Higher Risk When
When the flow is used for high-privilege integrations that lack PKCE (Proof Key for Code Exchange) as a secondary defense or when secrets are stored in plain-text client-side repositories.
Low Risk When
When "Private Clients" strictly enforce secrets stored in secure server-side vaults and "Public Clients" use PKCE to secure the exchange without needing a vulnerable shared secret.
Business and Integration Considerations
Implementing this correctly requires a clear architectural distinction between backend-driven and frontend-driven applications to make sure that the appropriate "Secret" policy is applied without breaking the authentication handshake.
Recommended Remediation
For private/server-side clients, select both "Require Secret for Web Server Flow" and "Require Secret for Refresh Token Flow"; For public/mobile clients, deselect these options and implement PKCE instead.
Security Health Review Guidance
Security Health Review highlights that the security of a secret depends entirely on the client's ability to protect it, and mandates that no shared secrets ever be exposed to the browser or mobile environment.
