Skip to content
SteveTechArcSteveTechArc Courses

Borrowed Trust

Module 3 of 5 in the chapter Acting as Someone: The Impersonation Flows, chapter 11 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: What if security won’t give one system the golden pass, but both sides already trust an identity provider?

The security team said no

Section titled “The security team said no”

I had a client where Salesforce needed to send changes into another big system, their ERP, and every change had to go in as a specific person. Nobody would be there: the changes came from automation in Salesforce. That’s module 1’s problem exactly.

The obvious answer was the golden pass from module 2: give Salesforce a certificate the other system trusts, and let it sign as anyone. So who did that make unhappy? The other system’s security team. With a golden pass, Salesforce could pretend to be anyone in their system. They said no.

But they did have something already: a single sign-on server, the company’s identity provider. The other system trusted it. And the integration layer between them could be trusted by it too. So we didn’t create a new trust. We borrowed one.

Here’s how it worked. Salesforce sent an event with only the person’s username in it. Not the password. Put a password in an event and anyone who can read the event can sign in as that person: the worst system in the world. Just the username. The integration layer, which the identity provider trusted, asked the identity provider for a SAML assertion for that person. The identity provider signed one. And the integration layer presented it to the other system, which believed it because it trusted the identity provider’s signature. No golden pass anywhere.

Into Salesforce, the same way

Section titled “Into Salesforce, the same way”

Now turn it around, into Salesforce. Same cells as modules 1 and 2. The third lane, empty until now, becomes the identity provider both sides trust.

Borrowed trust The same four lanes and cells as before, with the third lane now the identity provider both sides trust. Before anything, the Burger House and Salesforce both trust the identity provider, and the Burger House has no golden pass of its own; Salesforce trusts the identity provider's signature. Priya isn't there. Step 1: her standing order is due, and the Burger House has only her username, never a password. Step 2: it asks the identity provider, with its own credentials, for an assertion, sending Priya's username; the identity provider signs a SAML assertion naming Priya and sends it back. Step 3: the Burger House presents the assertion at Salesforce's token endpoint, which checks the signature and who it names; the check passes and it returns an access token, with no refresh token. Step 4: the Burger House fetches her drink from the API as Priya. Footnote: nobody holds a golden pass into Salesforce; the identity provider decides whom it will sign for. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-AS-03", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} PRIYA THE BURGER HOUSE THE IDENTITY PROVIDER BOTH TRUST SALESFORCE: TOKEN ENDPOINT AND API Before: both trust the identity provider no golden pass of its own Salesforce trusts the identity provider's signature Priya: not there asleep, away, or never signs in 1. Her standing order is due it has only her username, never a password 2. Asks for an assertion with its own credentials The identity provider signs an assertion naming Priya 3. Presents the assertion at Salesforce's token endpoint The token endpoint checks the signature and who it names 4. Fetches her drink as Priya: her access, her name on changes The API what Priya may see trust set up trusts its signature Priya's username a signed assertion the assertion access token, no refresh the access token her data Nobody holds a golden pass into Salesforce. The identity provider decides whom it will sign for. HOW TO READ IT Salesforce the check passes © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The Burger House has only Priya’s username. It asks the identity provider for an assertion. The identity provider decides whether to sign for her, and signs. The Burger House presents the assertion at Salesforce’s token endpoint, and gets an access token for Priya.

It’s still the same shape as module 1: present something signed, naming her, and get a token. The only difference is whose signature it is.

Almost the same name

Section titled “Almost the same name”

Salesforce has two flows that use a SAML assertion here, and they have almost the same name. They do different things.

Two SAML flows, almost the same name Two SAML flows side by side. The SAML bearer assertion, grant type saml2-bearer, is made by the client, which builds it and signs it with its own key, and is checked against an app with the certificate, for a user who approved before. The SAML assertion flow, grant type assertion, is made by the identity provider, the same assertion as for single sign-on, and is checked against the org's single sign-on setting, with no app, but limited to one org, with no login flows and no Experience Cloud sites; amber marks those limits. Footnote: both are one step, give an access token, and never a refresh token. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-AS-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE FLOW WHO MAKES THE ASSERTION WHAT SALESFORCE NEEDS SAML bearer assertion grant type saml2-bearer The client builds it and signs it with its own key An app with the certificate and the user approved before SAML assertion flow grant type assertion The identity provider the same assertion as for single sign-on The org's single sign-on setting no app; one org, no login flows, no sites made by checked against made by checked against Both: one step, an access token, and never a refresh token. HOW TO READ IT limits to know before you choose it © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The SAML bearer assertion flow (S3). The key thing: the assertion is created on the client. The client builds a SAML assertion naming the user and signs it with its private key, and the app in Salesforce holds the matching certificate. Salesforce checks the signature and “the audience, issuer, subject, and validity of the assertion” (S3):

  • Issuer: the app’s client ID.
  • Audience: https://login.salesforce.com or https://test.salesforce.com.
  • Recipient: the token endpoint.
  • Subject: the user’s Salesforce username.

It’s posted with grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer, and like JWT bearer, it takes no scopes and “doesn’t support refresh tokens” (S3). It needs the user or admin to have approved the app before.

Look closely and you’ll see it’s the golden pass again, in SAML instead of JSON: the client holds a key Salesforce trusts. It’s the choice when the client already speaks SAML better than JWT. Sign it with SHA-256 (chapter 3); the page still allows SHA-1 (S3).

To be fair to the platform, and to you: Salesforce’s page for this flow still says “connected app” throughout (S3), while new apps are external client apps (chapter 7). This course hasn’t yet tried the SAML bearer assertion flow with an external client app, so check Salesforce’s current page for this flow before you build one.

The SAML assertion flow (S4). Here the assertion is taken from the identity provider. In Salesforce’s words, it’s “an alternative for orgs that use SAML to access Salesforce and want to access the API the same way.” If your org already has SAML single sign-on (chapter 6), the same assertion the identity provider makes for logging in can be exchanged for an API token, and “You can use this assertion flow without a connected app” (S4). It’s posted with grant_type=assertion and an assertion_type of urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser, and “A refresh_token is never issued in this flow” (S4).

That’s the purest borrowed trust: nothing new to set up in Salesforce. But it has limits to know before you choose it (S4):

  • One org only: “You can’t use this flow with more than one org.”
  • No login flows: it doesn’t run them.
  • No Experience Cloud sites: they don’t support it.

And there’s more sensitivity in it: the identity provider has to make the assertion exactly right for this use, with the right audience and recipient. Getting that configured can be the hard part.

Choosing

Section titled “Choosing”

If you ever hear a requirement to use a specific user, and nobody’s there to sign in, these are your choices:

  1. The tightest trust there is: JWT bearer (module 2), or the SAML bearer assertion if the client speaks SAML. One system holds a key Salesforce trusts. Only between systems you control.
  2. Borrowed trust: is there an identity provider around that both sides already trust? Then let it decide, and sign: the SAML assertion flow into Salesforce, within its limits. Nobody holds a golden pass.

Both are the same thing underneath: present something signed, naming her, and get a token. The difference is only who you trust to sign.

And whichever you choose: no passwords in events, messages, or logs. Ever.

Test knowledge. In my experience, know the difference between the two SAML flows: the SAML bearer assertion is built and signed by the client, with a certificate on the app; the SAML assertion flow reuses the org’s SAML single sign-on, without an app.

Watch it on video

Section titled “Watch it on video”

In 2023 I made a video of the two SAML flows with almost the same name, the one made on the client and the one taken from the identity provider. The note under the video says what’s still right and what’s changed since.

STA 3.18 · Salesforce OAuth SAML Bearer Assertion and SAML Assertion Flow · 8:45 · published 2023-10-16 · plays from YouTube when you click it · Watch on YouTube · More videos: Salesforce Identity & Access Videos

What’s next

Section titled “What’s next”

Module 4: token exchange. When Priya is signed in, just somewhere else.

What an architect decides here

Section titled “What an architect decides here”
  • Whether to create a new trust or borrow one that already exists.
  • Which SAML flow, if any, and whether its limits fit: one org, no login flows, no sites.
  • Who the identity provider will sign for, and who decides that.
  • That no password ever travels in an event or a message.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.