• When a user is signed into SF with Azure AD identity provider (SSO), we want to send the current identity (in the form of a Saml assertion, bearer token, etc?) along with the external API callout request, to auth the API call. Do you have any advice, guidance, or tips based on your experience?


  • We have watched https://www.pluralsight.com/courses/play-by-play-salesforce-understanding-single-sign-on
  • We have read numerous, numerous tutorials and documentation pages in Salesforce, Azure, and various blogs.
  • We have successfully implemented SSO with Azure AD (SAML based).
  • We are in the process of figuring out how to set up Auth Provider to Azure AD as well, as another approach option.
  • We are also building the external API - the API could accept OpenID or SAML based auth info - we're in control. We're posting data in the outbound callout to this external API (SF -> API).


  • The issue we're facing is trying to figure out how to send the auth (either Saml assertion or Oauth token from user's session) along with the external API callout request.
  • There is no clear how-to documentation or example code on how to do this.

Possible approaches we've brainstormed / we're exploring:

  1. Saml to SSO user into SF. This is our fallback approach if none of the others below work. All the code would be in Apex. We would use "client credential" flow to establish machine-to-machine connection between SF and the External API. This does not use the signed in user's credentials though so it's not really achieving the use case of leveraging the current user's logged in session (api call audit trail..). But maybe it's the only way we can make the external callout work?
  2. Saml to SSO user into SF. Then all API external calls happen in a Lightning Web Component (LWC)? There is little or no Apex code here. This would be let the browser and javascript handle saml redirects when invoking the API with a post. This option is all theory at this point and I don't actually know how it would work and I cannot find any sample code.
  3. Saml to SSO user into SF. Then exchange a saml assertion for oauth token: https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/19728688-support-for-oauth-2-0-saml-bearer-assertion-flow The code would all be in Apex. I cannot find any sample code to support this approach. And I'm not even sure how to access or build a Saml assertion when in Apex code.
  4. Named credential approach. Could use either Saml SSO or Azure AD Auth Provider (using Open ID Connect) to sign user into SF. Or have both where Saml handles SSO and Auth Provider handles API auth. The Named credential would pass the auth info to external API? I know you can reference an Auth Provider in the Named Credential but I cannot find how to configure Named Credentials with Saml SSO only. Apex code would reference the Named Credential and "Just work"? I cannot find example Apex code though, other than something like this. . . but how is auth set?
    Http http = new Http();
    HttpRequest request = new HttpRequest();
    request.setHeader('Content-Type', 'application/json;charset=UTF-8');
    HttpResponse response = http.send(request);
    return response;
  • You're suffering from a Paradox of Choice. You should first build your API and decide how the calls to your API will be authorized, then come back to Salesforce. APIs are usually authorized via oAuth. How to obtain an oAuth token that could be used with an API depends on identity & access infrastructure tied to said API. Out of the box, Named Credential supports some of these possible options. Hand-coding it in Apex allows you to work with many other options. For server-to-server (aka A2A) calls, look at JWT profile of oAuth authorization grant type
    – identigral
    Aug 25, 2020 at 22:44
  • @identigral - "Paradox of Choice" - such an interesting concept. Thanks for pointing it out. Yeah casting a wide net to see what the options are then narrowing it down from there. I think the initial thought is have the API authorized via OAuth, so that would rule out the option #2 I mentioned above. But I was hoping there was a standard approach - a cookie cutter approach. Seems that this cannot be a unique use case and many others have solved it before. Why is it so hard to find detailed documentation of these solutions online? Aug 26, 2020 at 0:09
  • JWT with Named Credentials is fairly straightforward. If your API will conform to this profile (see link in our comment above), then connecting them together isn't a lot of effort.
    – identigral
    Aug 26, 2020 at 0:17
  • 1
    Im going back to basics and reading up on the entire topic as a whole: amazon.com/… If there are any other recommended learning resources @identigral, please pass them along! Aug 31, 2020 at 19:30
  • @JoelHoward, did you have the chance to check how many seconds it takes to validate the token? If that takes longer than 10 seconds, you will receive this error as well Mar 12, 2021 at 7:44

3 Answers 3


We went with SAML SSO, Azure App registration (when publishing API), Auth Provider in SF (to get token for use with API), and Named Creds (to tie it all together):




You don't need to do anything custom. If you use open ID connect then the authentication provider will store the access token and the refresh token in the platform for you so that when you want to call out to your third party system you can simply use Apex to retrieve those tokens. Note that the refreshing of the token is also handled for you.

That said this only applies if you use open ID connect to begin with


Have you considered using a custom login flow? https://help.salesforce.com/articleView?id=security_login_flow_examples.htm&type=5

This would execute as part of the user authentication process.

You can use an APEX class in your login flow to call your external web service / API endpoint.

Re: named credential in APEX, please refer to the ff. link: https://help.salesforce.com/articleView?id=named_credentials_about.htm&type=5

  • Thanks for the reply. I've scoured this documentation top to bottom but am I missing something - to me it doesnt go into any detail about the use case described in the original question. It just glazes over it at a surface level. But thanks again for the reply and the thoughts Aug 25, 2020 at 22:04
  • Here's the process I had in mind: 1. User authenticates through Federated SSO (SAML) 2. User is redirected to a custom login flow that you setup 3. the Login flow has APEX code which does the callout to your external web service / API endpoint passing info you require on the other end. Hope this helps Aug 25, 2020 at 23:40
  • I like that - thanks again Aug 26, 2020 at 0:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .