Manage OAuth Access Policies for a Connected App

• All users may self-authorize—Default. Allows all users in the org to authorize the app after successfully signing in. Users must approve the app the first time they access it.
• Admin approved users are pre-authorized—Allows only users with the associated profile or permission set to access the app without first authorizing it. After selecting this option, manage profiles for the app by editing each profile’s Connected App Access list. Or manage permission sets for the app by editing each permission set’s Assigned Connected App list.

  In a Group Edition org, you can’t manage individual user access with profiles. However, you can manage all users’ access when you edit a connected app’s OAuth settings.

  

  Warning If you switch from All Users may self-authorize to Admin-approved users are pre-authorized, anyone using the app loses access, unless a user’s permission authorizes the connected app specifically. Connected apps that are part of a managed package use the default permission. In addition, if users have the Use Any API Client permission, they can access any connected app—even if its Permitted Users setting is set to Admin-approved users are pre-authorized. Be careful when using the Use Any API Client permission. As the name implies, you’re giving up your control over authorization.

• Enforce IP restrictions—Default. Enforces the IP restrictions configured for the org, such as the IP ranges assigned to a user profile.
• Enforce IP restrictions, but relax for refresh tokens—Enforces the IP restrictions configured for the org, such as the IP ranges assigned to a user profile. However, this option bypasses these restrictions when the connected app uses refresh tokens to get access tokens.
• Relax IP restrictions for activated devices—Allows a user running the app to bypass the org’s IP restrictions when either of these conditions is true.
  • The app has a list of allowed IP ranges and is using the web server authentication flow. Only requests coming from these IPs are allowed.
  • The app doesn’t have a list of allowed IP-ranges, but it uses the web server authentication flow, and the user successfully completes identity verification if accessing Salesforce from a new browser or device.
• Relax IP restrictions—Allows a user to run this app without org IP restrictions.

Note If you relax IP restrictions for your connected app and your org has Enforce login IP ranges on every request enabled, the access to your connected app can change. See Connected App IP Relaxation and Continuous IP Enforcement. Also, IP restrictions are enforced only if they are configured on a user’s profile. The SAML bearer assertion and JWT bearer token flows always enforce IP restrictions regardless of the connected app policy. Connected apps that are part of a managed package use the default IP relaxation setting.

If refresh tokens are provided, users can continue to access the OAuth-enabled connected app without having to reauthorize when the access token expires (defined by the session timeout value). The connected app exchanges the refresh token with an access token to start a new session. The Refresh Token policy is evaluated only during usage of the issued refresh token and doesn’t affect a user’s current session. Refresh tokens are required only when a user’s session has expired or isn’t available.

For example, you set a refresh token policy to expire the token after 1 hour. If a user uses the app for 2 hours, the user isn’t forced to reauthenticate after 1 hour. However, the user is required to authenticate again when the session expires and the client attempts to exchange its refresh token for a new session.

• Refresh token is valid until revoked—Default. The refresh token is used indefinitely, unless revoked by the user or Salesforce admin.

  Revoke tokens on a user’s detail page under OAuth Connected Apps or on the OAuth Connected Apps Usage Setup page.

• Immediately expire refresh token—The refresh token is invalid immediately. The user can use the current session (access token) already issued, but can’t obtain a new session when the access token expires.
• Expire refresh token if not used for n—The refresh token is valid as long as it’s been used within the specified amount of time. For example, if set to seven days, and the refresh token isn’t exchanged for a new session within seven days, the next attempt to use the token fails. The expired token can’t generate new sessions. If the refresh token is exchanged within seven days, the token is valid for another seven days. The monitoring period of inactivity also resets.
• Expire refresh token after n—The refresh token is valid for a fixed amount of time. For example, if the policy states one day, the user can obtain new sessions only for 24 hours.