Authentication with external systems can be a pain, especially for developers, as they must develop logic to deal with user credentials and access tokens. This can be time-consuming to understand and implement. It’s also simply a less efficient way of dealing with Authentication for external system integrations for Salesforce solutions.
This is where ‘Named Credentials’ and ‘Auth Providers’ come in, as they can provide a simple, efficient, and effective process for dealing with Authentication. We will first briefly explain what each is and then how they work together to handle authentication.
NOTE: You can integrate one Salesforce instance with another by creating a connected app within Salesforce first and then following similar steps in the link below. When integrating with any other system, a connected app must be created. To do this check out the link below: https://help.salesforce.com/s/...
What are Auth Providers in Salesforce?
An authentication provider is a feature that enables users to log into the Salesforce platform using credentials from an external identity provider (IDP). An authentication provider allows Salesforce to authenticate a user's identity using the authentication mechanisms provided by the external IDP, rather than requiring the user to log in with a separate Salesforce username and password.
Salesforce includes several built-in authentication providers for well-known external systems like Facebook, Microsoft, and Google. However, custom authentication providers can be set up for systems that operate over Open ID protocol or systems that support OAuth 2.0. This is basically a single sign-on (SSO) solution which allows a Salesforce Org to access protected third-party data from external systems by defining authentication property values that the external system requires.
To set up an authentication provider in Salesforce, follow these steps:
- Navigate to Setup > Security > Auth. Providers in the Salesforce menu.
- Click the New button to create a new authentication provider.
- Select the type of authentication provider that you want to create, such as OpenID Connect, SAML or Microsoft Access Control Service
- Enter the relevant details for the authentication provider, such as the URL and issuer for the external system, and any other required information.
- Click the Save button to save the authentication provider.
- You can then test the authentication provider by clicking the Test button, or you can use it to create a named credential (see below for more information on named credentials).
Keep in mind that the specific steps and details for setting up an authentication provider may vary depending on the type of provider and the external system that you are connecting to. You may need to consult the documentation or support resources for the external system to get the correct information.
Below is an example of an authentication provider that was set up for a Microsoft SharePoint Integration for one of our clients:
What are Named Credentials in Salesforce?
Named credentials are simply a way to store and manage the authentication details required to connect to an external system. This can include information such as the URL, username, and password for the external system, as well as any other relevant details such as the protocol (e.g. OAuth) and the authentication provider as previously discussed. Essentially, a named credential defines the URL callout endpoint and the authentication parameters required for a specified external system.
By using named credentials, users can easily connect to external systems without having to hard-code the authentication details into their Salesforce code or configuration. This makes it easier to manage and update the authentication details and helps to ensure that sensitive information is not exposed.
For any Apex callouts that mention a named credential, Salesforce can then handle/manage the authentication process automatically. Named credentials utilise authentication providers during the authentication process.
To set up a named credential in Salesforce, follow these steps:
- Navigate to Setup > Security > Named Credentials in the Salesforce menu.
- Click the New button to create a new named credential.
- Enter a name for the named credential, as well as the URL and any other relevant details for the external system.
- Select the authentication provider that should be used to connect to the external system.
- Enter the username and password for the external system, or select the option to use a named principal if you want to use a different authentication method.
- Click the Save button to save the named credential.
- You can then use the named credential in your Salesforce code or configuration to connect to the external system.
Note: The specific steps and details for setting up a named credential may vary depending on the type of external system and the authentication provider that you are using. You may need to consult the documentation or support resources for the external system to get the correct information.
Below is an example of a named credential that has been set up for a Microsoft SharePoint Integration for one of our clients, which uses the authentication provider from the previous example:
One of the key advantages of using named credentials and authentication providers is that they provide a standardized way to connect to external systems. This means that once an authentication provider has been created for a particular type of external system, it can be used by any Salesforce user to easily connect to that system.
This makes it much easier to integrate with external systems and helps to ensure that the authentication process is consistent and secure across the entire Salesforce environment.
Using named credentials and authentication providers can also save time and frustration for both Salesforce users and developers. For example, imagine that you are trying to connect to an external system, but you don't have the correct authentication details. Without named credentials, you would have to go through the time-consuming process of figuring out the correct URL, username, and password, and then hardcode that information into your Salesforce code or configuration. But with named credentials, you can simply select the correct named credential from a dropdown menu, and Salesforce will take care of the rest. This can save a lot of time and headaches, especially if you are working with multiple external systems and must manage multiple sets of authentication details.
Below is an example of how a named credential can be used directly within Apex code for external system integrations, in this case, a Microsoft SharePoint Integration and the method involves renaming a file/folder through Microsoft Graph API:
As you can see, there is no logic for authentication within this code as it is all externalised through the named credential. The only part that needs to be specified for the authentication is the named credential name, in this case, ‘sFilesConnection’. This is brilliant for development as it makes it easier to manage credentials between different environments as the named credential configuration is externalised as setup configuration in the org.
Another benefit of using named credentials and authentication providers is that they can help prevent common errors and mistakes. For example, let's say that you have a number of different Salesforce users who are all trying to connect to the same external system. Without named credentials, each user would have to enter their own authentication details, which could easily lead to mistakes or inconsistencies. With named credentials, all the users can simply use the same named credential by choosing the identity type ‘Named Principal’ during its set-up, which ensures that they are all using the same authentication details. This can help to prevent errors and also ensures that everyone is using the same, up-to-date authentication information.
In short, named credentials and authentication providers are like a pair of trusty sidekicks for Salesforce users who are trying to integrate with external systems. They help to ensure that the authentication process is secure, consistent, and error-free, and can save a lot of time and frustration along the way.
Today’s post was written by Salesforce Developer, Peter McKeever.