Connected Apps

I am currently studying for both the Integration Architect and the Identity and Access Management Architect certification. These notes are highlights from the information I have been gathering to help me prepare for the certification from the Systems Architect track. I hope that they help you, too.

This article is focusing on Identity and Access relating to Connected Apps. This subject (like many in the Identity and Access exam) overlaps with the Integration Architect certification.

Connected Apps

A connected app is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and provide single sign-on (SSO) for external apps. The external apps that are integrated with Salesforce can run on the customer success platform, other platforms, devices, or SaaS subscriptions. 

Salesforce Help documentation: Connected Apps. 

Connected Apps are available for Salesforce Orgs as well as Experience Cloud sites. They are created for seamless integration and to assist with restricting what a user has access to via Connected App permissions and policies. They are used for External Systems to call into Salesforce (Inbound Integrations).

Here are the main use cases for a Connected App: 

• Data Access Through an API Integration
  A connected app can request data from Salesforce on behalf of an external application. The data is shared using the OAuth 2.0 protocol by exchanging tokens. The authorisation flow enables a user to see the data of an app different from the one they are working on. This type of Connected App can be used for devices with limited display or input capabilities: It could be a coffee machine, a TV or a command-line application. For these particular use cases, select Enable for Device Flow.
  
  This type of Connected App can use the Web Server Flow, the JWT OAuth Flow and / or the refresh token flow. You can find more on this topic in the Tag called ‘Integration’.
  
• External API Gateway Authorisation
  For these types of connected apps, Salesforce can act as an independent OAuth authorisation server.  Saleforce protects the resources hosted on the external API gateway. This connected app uses OpenID Connect Dynamic Client Registration for External API Gateways. Using this, resource servers dynamically create client apps as connected apps which Salesforce then authorises. A User can then access protected resources hosted on a third party service.
  
• Integrate Service Providers
  A Service Provider is a resource that you wish to access. For this connected app Salesforce acts as an Identity Provider for the Service Provider by using SAML Single Sign On or OpenID Connect tokens. With SAML Single Sign-On, users can seamlessly log onto a web app/service provider that implements SAML 2.0 for user authentication.
  
  With OpenID Connect, the connected app has OAuth settings enabled and the “Allow access to your unique identifier (openid)” scope applied. An ID token will also need to be configured. When all set, the OpenID Connect also provides a Single Sign-On experience with the connected service provider.
  
• Third Party App Access Management
  This type of Connected App use case enables Administrators to set security policies to control what data a third party can access from Salesforce. They can also determine which users can use the third party app. An admin can set the policy “Admin approved users are pre-authorised” and then apply access on a profile-by-profile basis. 

Creating a Connected App

• To create a connected app, go to App Manager in Setup and Click New Connected App.
• Complete the Basic Information which will include the Connected App’s name, and a Contact email as the minimum.
• Click the check box for ‘Enable OAuth Settings’ to assign scopes and other settings.
• Enter the callback URL. This is the endpoint that Salesforce calls back to the application during OAuth. Usually, this is the one that a user’s browser is redirected to after successful authorisation, although it does depend on the authorisation flow.
• Digital Signatures is typically selected if the JWT OAuth Flow is being used. Ticking this enables you to upload a certificate. 

• The next step is to select the appropriate OAuth scopes for your connected app. These are permissions which are granted as tokens after authorisation is complete. Do be selective on which scopes are chosen.
  
  For example, applying Full Access as a scope will enable the connected app to access all data accessible by the logged in user and every other scope in the available OAuth Scopes. Applying the ‘Manage Pardot Services’ will give access to Pardot API Services and allow them to manage the full extent of accessible Pardot services.
  
• The next two boxes are for Require Secrets for Web Server Flow and Refresh Token  Flow. If the app you are connecting to cannot keep the Client Secret protected, it must use the web server flow and the Require Secret for Web Server Flow should be deselected. Although there will still be a Client Secret, the Web Server Flow will not require it for an access token request. In the circumstance where a Client Secret cannot be kept confidential – Salesforce recommends User Agent Flow.
  
  The Require Secret for Refresh Token Flow should only be used for web server apps that keep Client Secrets protected (as above). What this does when it is selected is require the Client Secret in the refresh token authorisation request.
  
• By  default Connected Apps can only introspect their own tokens. Where you need a Connected App to introspect all – select the ‘Introspect all tokens’. Introspection is part of the authorisation process used by OAuth connected Apps to look at the current state of an access or refresh token. Introspection is essentially a validation of a token.
  
• Next comes the Configure ID Token checkbox. If your OAuth Request has the scope Allow Access to your unique identifier (openid) the access token response can contain the ID Token. You can set how long the Token is valid for, who should consume it, what information about the user is to be added  and custom attributes and permissions.
  
• Select Enable Asset Tokens, if the app is to issue connected device asset tokens. If you do you can set the length of time the asset token is valid for after issuing, if there is a self-signed certificate, who can consume it and again custom attributes and permissions.
  
• If you want, you can use Enable Single Logout to ensure that users are logged out of the Service Provider for  the Connected App at the same time they log out of Salesforce. The Endpoint that will need to be identified is listed in the Login Information as the Single Logout Endpoint.

Custom Connected App Handlers

Apex can be used to create a custom connected app handler and customise connected app behaviour. This way it can work in a way that works best for a necessary business process. A class is associated with the connected app that extends the ConnectedAppPlugin Apex Class. With this, the class can be set to Run as the execution user instead of the current user of the connected app. 

Canvas Apps

Canvas Apps are a subset of connected apps. Canvas Apps are part of the Salesforce User Interface either native to Salesforce or as legacy cloud apps. It is not accessible outside Salesforce unless it provides an alternative way to log in. An admin can set the access to: All users may self-authorise or Admin approved users are pre-authorised. The Canvas App access is controlled by profiles and permission settings. The App has full access to the user’s data. They need to be online Cloud Apps. 

Mobile Apps Integration

Using Connected Apps is the main way a mobile app connects to Salesforce. They generally use Salesforce OAuth Service and utilise the REST APIs. 

Set up the Connected App in the normal way and enable the OAuth Settings for the Callback URL (which the Mobile SDK uses this URL during authorisation). There are three scopes that will be needed:

• Access and manage your data (api)
• Perform requests on your behalf at any time (refresh_token, offline_access)
• Provide access to your data via the Web (web)

If the Mobile SDK app authorises through the mobile device’s browser – deselect the ‘Require Secret for Web Server Flow’. This is a prime example of not requiring this setting. 

There are other settings to be aware of (this is not a step-by-step guide). They include:

• Setting a Mobile Start URL if you don’t want the starting URL under Web App Settings and it is not a Canvas App Mobile Connected App. For Canvas Apps, the Start URL is in the Canvas App URL field.
• Setting up Pin Protect for Pin Protection
• Select an App Platform and Minimum OS version (Android, IOS)
• Restrict access to a device type (unless your app supports all form factors)
• Setting it as a private app if it is only for internal use
• Enabling push notifications

Salesforce as an Identity Provider

With Connected Apps, Salesforce is invariably the Identity Provider. An admin needs to enable the Salesforce org as an Identity Provider and exchange with the Service Provider the SAML Single Sign-on (SSO) information.

To do this – go to Setup and search for Identity Provider. From here you can download either metadata or certificates depending on what the Service Provider Supports. Interestingly, there is a SAML assertion lifetime of 5 minutes after it’s issued (plus a 30-second buffer). If the Service Provider receives the SAML response outside of the 5 minute lifetime, it will usually reject the assertion. 

After configuring the identity provider information, in the Connected App under the Web App Settings, you can Enable SAML and enter information relating to the globally unique ID of the service Provider (Entity ID), the endpoint (Assertion Consumer Service URL), subject type (which identifies the user’s identity for the connected app), Issuer (usually your My Domain) and the Name ID format (which can be an email address, persistent or transient).

There are additional settings where you can choose to have a unique certificate or the default IdP certificate (depending on your Service Provider’s requirements). If the Service Provider provides a security certificate, then select Verify Request Signatures and upload the certificate. This is usually only required if Salesforce will be logged in from the Service Provider.

Finally, you can Encrypt the SAML response (with a certificate) and select Signing Algorithm for SAML Messages to secure SAML messages sent from Salesforce.

Credit for Title Card Image goes to WikiCommons: https://commons.wikimedia.org/wiki/File:Computer-science-education.jpg