- With Named Credentials you define the endpoint and its authentication details declaratively. Using Named Credentials is a pattern all architects should be utilizing instead of trying to handle authentication details in your Apex code.
- Authentication is now separated from the endpoint definition. Separating them allows the same authentication configuration to be used for multiple endpoints. For example, you might authenticate against Google’s OAuth service, and then make calls to both the Google Drive API and the Google Calendar API. The endpoint is still defined via the Named Credential object, but now it has a lookup to something called an External Credential.
- The External Credential captures the authentication details, and the Named Credential holds the endpoint. The two are separate, but they work together. The connection between a Named Credential and an External Credential is a straightforward lookup, similar to how a Contact is related to an Account. You can view the External Credential and all the associated Named Credentials in a related list. And just like with Accounts and Contacts, you’ll want to create the External Credential first, and then create the Named Credential that looks up to it.
- Users who make callouts will also need access to a new standard object called User External Credentials. This object holds the actual encrypted access tokens or other secret values used to call out the external system.
- Named credentials reference external credentials, which specify authentication protocols and authorization information. In turn, external credentials use user external credentials to store encrypted authentication tokens. Any user performing an authenticated callout needs profile- or permission set-based access to user external credentials.You must enable user external credentials to make them accessible. There are two ways to enable user external credentials, via user profiles or permission sets.
- External credentials authenticate users, and permission sets authorize users. You link an external credential to permission sets or user profiles through principals. At run time, the platform ensures that the user has the permission set before accessing the remote system.
- When creating an External Credential, you now also create one or more Principals underneath it, each reflecting the identity of the caller in the external system. Many times, this identity is an “integration user” or “service account” that does not correspond to an individual human being. Principals like that typically hold an API key or other secret. The permissions make it explicit that a given User has been granted access to that key or secret, not in its raw form, but within the context of a callout. The callout will be blocked if the calling user hasn’t been granted permission to the Principal.
- The Named Credential object now has a Type field that functions like a Record Type designation. Newer credentials will be reflected with the Type of Secured Endpoint, and in the list view you can see both the Type and the associated External Credential. The original iteration of Named Credentials is reflected in the Type of Legacy. Legacy credentials store all settings on a single setup object. Older credentials don’t have a lookup to an External Credential.
Certified System Architect | Certified Application Architect | 19X Certified | Trainer | Double Ranger | Blogger
1 年References : https://help.salesforce.com/s/articleView?id=sf.nc_named_creds_and_ext_creds.htm&type=5https://medium.com/salesforce-architects/whats-new-with-named-credentials-c2b166506cd5