---
schema_version: "1"
id: 3f578ca0c5266d5bf15af3589fa7d99219f82fee8f7e8d491a856a458ff4f029
title: Block Authorization Flows to Improve Security
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/remoteaccess_disable_username_password_flow.md
canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_disable_username_password_flow.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 59117d0d659d5d7941a5b4a0f9dc5ea5b6e70df276fb56f5146a1fe81a3f7ca9
description: The OAuth 2.0 user-agent and username-password flows are considered insecure and aren’t recommended. For better security, we strongly recommend that you block these flows in Salesforce to prevent developers from using them to build new integrations. If your org is created in Summer ‘23 or later, the username-password flow is blocked by default. You can enable the username-password flow if needed. If you have existing integrations that use the user-agent or username-password flow, update them to a more secure OAuth 2.0 flow. You can also block the Authorization Code and Credentials Flow, which is used to securely configure a headless login process. And you can block certain flows that don’t use the PKCE extension.
products:
  - Security
  - Cross Cloud
release: "264"
---
# Block Authorization Flows to Improve Security

The OAuth 2.0 user-agent and username-password flows are considered insecure and aren’t recommended. For better security, we strongly recommend that you block these flows in Salesforce to prevent developers from using them to build new integrations. If your org is created in Summer ‘23 or later, the username-password flow is blocked by default. You can enable the username-password flow if needed. If you have existing integrations that use the user-agent or username-password flow, update them to a more secure OAuth 2.0 flow. You can also block the Authorization Code and Credentials Flow, which is used to securely configure a headless login process. And you can block certain flows that don’t use the PKCE extension.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: both Salesforce Classic and Lightning Experience</td></tr><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: <strong>All</strong> Editions</td></tr></tbody></table>

Blocking a flow can break managed packages, mobile apps, and other integrations that use it. Blocking the user-agent flow also blocks the hybrid app token flow. Before implementing your changes in production, test them thoroughly in a sandbox. In place of the user-agent flow for external web apps, we recommend using the OAuth 2.0 web server flow with Proof Key for Code Exchange (PKCE.) In place of the username-password flow, we recommend using OpenID Connect dynamic client registration or the OAuth 2.0 client credentials flow. For a list of alternative OAuth flows and their use cases, see [OAuth Authorization Flows](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_flows.htm&type=5&language=en_US).

1. From Setup, in the Quick Find box, enter OAuth, and then select **OAuth and OpenID Connect Settings**.
2. To block a flow, turn off its associated setting. To enable a blocked flow, turn on its associated setting. Here’s a list of the settings.
    
    - Allow OAuth User-Agent Flows—We recommend updating your integrations and blocking this flow.
    - Allow OAuth Username-Password Flows—We recommend updating your integrations and blocking this flow too.
    - Allow Authorization Code and Credentials Flows—Block this flow only if you aren’t using it.
    - Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows—This setting doesn’t explicitly block or enable a specific flow. Instead, when enabled, it blocks all variations of the OAuth 2.0 authorization code flow that don’t implement the PKCE extension. These variations include the web server flow, the hybrid web server flow, the Authorization Code and Credentials Flow, and all variations of the Authorization Code and Credentials Flow. This setting is a prerequisite for requiring the PKCE extension for a connected app and for using PKCE for an authentication provider. For more information, see [Proof Key for Code Exchange (PKCE) Extension](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_pkce.htm&release=264.0.0&type=5 "To improve the security of your OAuth and authentication provider implementations, use the OAuth 2.0 Proof Key for Code Exchange (PKCE) extension. You can require PKCE at an org-wide level, require it for a specific connected app, and automatically enable it for supported authentication providers.").
3. At the prompt from your browser, click **OK** to confirm that you’re ready to implement this change.
    
    ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-identity-264-0-0-production-enus/699dab6f-8f1a-4662-b24f-6521d5b747f7/images/icon_note.png)
    
    Note After a flow is blocked, you can’t use it to build new integrations. Existing integrations that use the blocked flow no longer work.

You can allow these flows at any time, but we don’t recommend ever allowing the user-agent or username-password flows. To use the Authorization Code and Credentials Flow, you must explicitly allow it.

#### See Also

- [OAuth 2.0 Username-Password Flow for Special Scenarios](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_username_password_flow.htm&release=264.0.0&type=5 "You can use the username-password flow to authorize a client via a connected app that already has the user’s credentials. However, we recommend avoiding this flow because it passes credentials back and forth. Use it only if there’s a high degree of trust between the resource owner and the client, the client is a first-party app, Salesforce is hosting the data, and other grant types aren’t available. In these cases, set user permissions to minimize access and protect stored credentials from unauthorized access.")
- [OpenID Connect Dynamic Client Registration for External API Gateways](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oidc_dynamic_client_reg_flow.htm&release=264.0.0&type=5 "Although not a typical authorization flow, you can use OpenID Connect dynamic client registration to enable your Salesforce instance as an independent OAuth authorization server to protect resources hosted on an external API gateway.")