Loading
Salesforce now sends email only from verified domains. Read More
Identify Your Users and Manage Access
Table of Contents
Select Filters

          No results
          No results
          Here are some search tips

          Check the spelling of your keywords.
          Use more general search terms.
          Select fewer filters to broaden your search.

          Search all of Salesforce Help
          Configure the External Client App OAuth Settings

          Configure the External Client App OAuth Settings

          Configure the OAuth settings to set the structure of the local external client app.

          Required Editions

          Available in: Lightning Experience
          Available in: Professional, Performance, Unlimited, and Developer Editions
          User Permissions Needed
          To configure External Client Apps OAuth settings Create, edit, and delete External Client Apps
          1. Create your external client app, and complete its basic information.
          2. In the OAuth Settings area of the page, select Enable OAuth.
            The OAuth Settings area expands and the OAuth settings fields are visible.
          3. Enter the callback URL (endpoint) that Salesforce calls back to your application during OAuth. It’s the same as the OAuth redirect URI.
            Depending on which OAuth flow you use, the URL is typically the one that a user’s browser is redirected to after successful authorization. Because this URL is used by some OAuth flows to pass an access token, the URL must use secure HTTPS or a custom URI scheme. If you enter multiple callback URLs, at run time Salesforce matches the callback URL value specified by the app with one of the values in Callback URL. It must match one of the values to pass validation.

            The Callback URL field has a limit of 2000 characters, cumulatively. Separate multiple callback URLs with line breaks.

          4. Select the OAuth scopes to apply to the external client app.
            OAuth scopes define permissions for the external client app, which are granted as tokens after the app is authorized. The OAuth token name is in parentheses.
          5. To authorize a single external client app to introspect all access and refresh tokens within the entire org, select Introspect all Tokens.
            By default, all external client apps can introspect their own tokens. In addition, an OAuth client that directly registers OAuth 2.0 external client apps through the dynamic client registration endpoint can check the tokens for itself and its registered apps.
          6. To control how the OAuth request handles the ID token, select Configure ID token.

            If the OAuth request includes the Allow access to your unique identifier (openid) scope, the returned token can include the ID token.

            The ID token is always included in access token responses.

          7. With the primary ID token setting enabled, configure the secondary settings that control the ID token contents in both access and refresh token responses. Specify these settings.
            SettingDescription
            Token duration in minutes The length of time that the ID token is valid for after it’s issued. The period can be from 1 to 720 minutes. The default is 2 minutes.
            ID Token Audiences The intended consumers of the ID token. For example, the target service where you use the ID token, such as https://your_service.com.
            Include Standard Claims Include the standard claims that contain information about the user, such as the user’s name, profile, phone number, and address. The OpenID Connect specifications define a set of standard claims to be returned in the ID token.
            Include Custom Permissions If your app has specified custom permission, include them in the ID token.
            Custom Attributes If your app has specified custom attributes, include them in the ID token.
          8. Enable an OAuth flow, and configure these settings, as needed.
            Configure settings for the client credentials flow See Configure a Client Credentials Flow
            Configure settings for the Authorization Code and Credentials Flow See Configure a Code and Credentials Flow.
            Configure settings for a device flow See Configure a Device Flow
            Configure JSON Web Token (JWT)-based access tokens See Configure a JWT Bearer Flow
          9. To require the app’s client secret in exchange for an access token, select Require Secret for the Web Server Flow.
            Important
            Important If the client app can’t keep the client secret confidential and must use the web server flow, deselect Require Secret for Web Server Flow. We still generate a client secret for your app, but this setting instructs the web server flow not to require the client_secret parameter in the access token request.
          10. To require the client secret in the authorization request of a refresh token and hybrid refresh token flow, select Require Secret for Refresh Token Flow.

            If you don’t select this option and an app sends the client secret in the authorization request, Salesforce still validates it.

            You can select this option for web-server based apps that can protect client secrets. But for apps that can’t protect client secrets, such as mobile apps or apps installed on a user’s computer, we recommend against selecting this option.
          11. To require PKCE, select Require Proof Key for Code Exchange (PKCE) extension for Supported Authorization Flows.
            This setting requires PKCE for the web server flow, the hybrid web server flow, and the Code and Credentials flow. It also requires PKCE for all variations of the Code and Credentials flow including headless registration, headless passwordless login, and headless identity for guest users. With this setting enabled, any of these flows that don’t implement PKCE are blocked for this external client app. For more information on using PKCE to secure your apps, see Proof Key for Code Exchange (PKCE) Extension.
          12. To get a new refresh token each time the refresh token flow is invoked, select Enable Refresh Token Rotation.
            Important
            Important Enabling this setting is a security best practice. With this setting enabled, the old refresh token is automatically invalidated after it’s used, so that each token is used only one time. If someone tries to use a refresh token that’s been rotated out, Salesforce invalidates the current refresh token and any associated access tokens.
          13. To get access tokens for users, select Issue JSON Web Token (JWT)-based access tokens for named users.
          14. After you configure the settings for your external client app, save your changes.
          • Set IP Allowlist Ranges for Refresh Tokens
            To improve security and help protect your Salesforce data from unauthorized access, set an IP range to allow refresh tokens. When you turn on Enforce Refresh Token IP Allowlist, only IPs in allowed ranges can complete the OAuth web server flow or the refresh token flow.
          • Limit the Idle Refresh Token TTL in External Client Apps
            For improved security, set a 30-day limit to the idle refresh token TTL (time-to-live). The idle TTL is the amount of time that a refresh token can be inactive before it expires. The idle TTL works as a sliding window: each time the token is used within the 30 day-period, its idle TTL resets. As an app developer, when you turn on this limit, it affects refresh token policies for your subscribers.
           
          Loading
          Salesforce Help | Article