ISVforce Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Editing a Connected App

Connected Apps can be created in: Group, Professional, Enterprise, Performance, Unlimited, and Developer Editions

Connected Apps can be installed in: All Editions

User Permissions Needed
To read: “Customize Application”
To create, update, or delete: “Customize Application” AND either

“Modify All Data” OR “Manage Connected Apps”
To update all fields except Profiles, Permission Sets, and Service Provider SAML Attributes: “Customize Application”
To update Profiles, Permission Sets, and Service Provider SAML Attributes: “Customize Application” AND “Modify All Data”
To uninstall: “Download AppExchange Packages”

The Connected App Edit page allows you to edit settings and permissions for a connected app.

Follow these steps to edit settings for a connected app.
  1. From Setup, click Manage Apps | Connected Apps.
  2. Click Edit next to the name of the app you want to modify. (To review information about an app on the connected app Detail page, click the app name.)
  • OAuth policies are available for every connected app.
    • Permitted Users determines who can run the app.
      • All Users may self-authorize: Default. Anyone in the organization can self-authorize the app. This means each user has to approve the app the first time they access it.
      • Admin-approved users are pre-authorized: Access is limited to those users with a profile or permission set specified, but these users don’t need to approve the app before they can access it. Manage profiles for the app by editing each profile’s Connected App Access list. Manage permission sets for the app by editing each permission set’s Assigned Connected Apps list.

      If you switch from All Users may self-authorize to Admin-approved users are pre-authorized, anyone currently using the app will lose their access unless they belong to a permission set or profile you have specified for the app.

      Note

    • IP Relaxation refers to the IP restrictions that the users of the connected app are subject to. An administrator can choose to either enforce or bypass these restrictions by choosing one of the following options.
      • Enforce IP restrictions: Default. A user running this app is subject to the organization’s IP restrictions, such as IP ranges set in the user’s profile.
      • Relax IP restrictions with second factor: A user running this app bypasses the organization’s IP restrictions if either of these conditions are true:
        • The app has IP ranges whitelisted and is using the Web server OAuth authentication flow. Only requests coming from the whitelisted IPs are allowed.
        • The app has no IP range whitelist, is using the Web server or user-agent OAuth authentication flow, and the user successfully completes Identity Confirmation.
      • Relax IP restrictions: A user running this connected app is not subject to any IP restrictions.
    • Refresh Token Policy specifies the validity period for a refresh token. Refresh tokens are used by the connected app to obtain new sessions without requiring the user to provide their credentials. The connected app simply exchanges the refresh token for a new session. Using refresh token policies, administrators control how long a refresh token may be used. Options include the following.
      • Refresh token is valid until revoked. This is the default behavior, and specifies that the token may be used indefinitely, unless revoked by the user or administrator. Revoke tokens in a user’s detail page under OAuth Connected Apps, or in the OAuth Connected Apps Usage report.
      • Immediately expire refresh token. This setting specifies the token is immediately invalid. The user may use the current session (access token) already issued, but cannot use the refresh token to obtain any new sessions.
      • Expire refresh token if not used for n. This setting invalidates the token if it is not used for the amount of time specified. For example, if the field value states 7 days, and the refresh token is not exchanged for a new session within seven days, the next attempt to use the token fails. The token expired and can no longer generate new sessions. If the refresh token is successfully used before 7 days, monitoring the period of inactivity resets, and the token is valid for another 7 days.
      • Expire refresh token after n. This setting invalidates the refresh token after a fixed amount of time. For example, if the policy states 1 day, the refresh token may be used to obtain new sessions for 24 hours. After 24 hours, the token can not be used to obtain new sessions.

      The Refresh Token Policy is only evaluated during usage of the issued refresh token, and does not directly impact a users current session. A user's session may be maintained by usage, and it's validity period is defined in Setup, Security Controls | Session Settings. Refresh tokens are only required when a user's session has expired or is no longer available. For example, if you set a Refresh Token Policy to Expire refresh token after 1 hour, and the user uses the application for two hours, they will not be forced to authenticate after one hour. They will only be required to re-authenticate when the session has expired and the client attempts to exchange its refresh tokens for a new session.

    • The current permissions for the connected app are also listed here.
    If your connected app is a canvas app that uses signed request authentication, be sure to:
    • Set Permitted Users to Admin-approved users are pre-authorized.
    • Set Expire Refresh Tokens to The first time they use this application.
    • Give users access via profiles and permission sets.
  • Session Level Policy is available for all connected apps. Select High Assurance session required to require users to enter a time-based token during login to access the app.
  • Basic Information is available for all connected apps. However, if your app is a canvas app, these field values aren’t used. Instead, the canvas app URL that was specified when the connected app was created is used.
    • Start URL is used if the connected app uses single sign-on. In this case, set the URL to the page where the user starts the authentication process. This location will also appear in the application switcher menu.
    • Mobile Start URL is used to direct users to a specific location when the app is accessed from a mobile device.
  • Mobile App settings are available for mobile connected apps that enforce pin protection.
    • Require PIN after specifies how much time can pass while the app is idle before the app locks itself and requires the PIN before continuing. Allowable values are none (no locking), 1, 5, 10, and 30 minutes. This policy is only enforced if a corresponding Pin Length is configured. Enforcement of the policy is the responsibility of the connected app. Apps written using the Salesforce MobileSDK can automatically enforce this policy, or the app may read the policy from the UserInfo service and enforce the policy itself.

      This setting does not directly invalidate a user's session. While the session may expire due to inactivity, this policy simply requires the user to enter their PIN in order to continue using their current session.

      Note

    • Pin Length sets the length of the identification number sent for authentication confirmation. The length can be from 4 to 8 digits, inclusive.
  • Custom Attributes are available for all connected apps. Developers can set custom SAML metadata or custom OAuth attributes for a connected app. Administrators can delete or edit those attributes. Administrators can also add additional custom attributes. Attributes deleted, edited, or added by administrators override attributes set by developers. For more information, see Editing, Packaging, or Deleting a Connected App.