Skip to content
SteveTechArcSteveTechArc Courses

Beyond Salesforce

Module 5 of 6 in the chapter Salesforce as the Identity Provider, chapter 7 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: Which Salesforce technologies let another system trust Salesforce for who someone is, and which do you choose?

The service provider doesn’t have to be Salesforce

Section titled “The service provider doesn’t have to be Salesforce”

So far in this chapter, the app that trusts Salesforce has been another Salesforce org. That’s the clearest way to learn it, because you control both sides. But most of the time, the other app isn’t Salesforce at all. It’s a benefits site, a cloud console, a scheduling tool, an app your own team built.

Salesforce’s own example is a custom web app for employee benefits: you want your users to log in to it with their Salesforce credentials (S10). The other app doesn’t care that Salesforce is Salesforce. It only cares that someone it trusts says who the person is, in a language it understands.

So the first question is: what does the other app speak?

Three ways Salesforce vouches

Section titled “Three ways Salesforce vouches”
The ways Salesforce vouches for someone Two columns: how Salesforce vouches, and the other app. Row 1: a SAML identity provider, with Enable Identity Provider and a SAML-enabled app, sends a signed SAML assertion to another Salesforce org, the lab's service provider org; taught in this chapter. Row 2: the same SAML identity provider, with custom attributes if needed, sends a signed SAML assertion to an app that speaks SAML, such as a benefits app or a cloud console. Row 3: an OpenID Connect provider, an app with the openid scope and no Enable Identity Provider, sends an ID token to a web or mobile app that asks Salesforce who the person is; chapter 9. Row 4: an Experience Cloud site as the identity provider, with its own issuer, sends an assertion or an ID token to an app for customers or partners, who sign in with their site login; chapter 14. Footnote: choose by what the other app speaks, and by who the people are. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-IDP-03", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} SALESFORCE VOUCHES AS THE OTHER APP A SAML identity provider Enable Identity Provider; a SAML-enabled app · this chapter Another Salesforce org the lab: the service provider org A SAML identity provider the same setup; custom attributes if it needs more An app that speaks SAML a benefits app, a cloud console An OpenID Connect provider an app with the openid scope; no Enable Identity Provider · ch 9 A web or mobile app that speaks OpenID Connect it asks Salesforce who the person is An Experience Cloud site the site as the identity provider, its own issuer · ch 14 An app for customers or partners they sign in with their site login a signed SAML assertion a signed SAML assertion an ID token an assertion or an ID token Choose by what the other app speaks, and by who the people are. HOW TO READ IT taught in this chapter named here, taught later © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

SAML: the one you just built

Section titled “SAML: the one you just built”

If the other app speaks SAML, the setup is the one from modules 2 to 4. You enable Salesforce as an identity provider, register the app as a SAML-enabled app, and say who may go. The other app takes Salesforce’s metadata and certificate. Some apps can read the metadata straight from an address: Salesforce publishes one for your My Domain, and its own example of an app that uses it is Amazon Web Services (S1).

What changes from app to app is what the app needs to know about the person. That’s the subject type: what Salesforce puts in the assertion to name her. Salesforce can send her username, her Federation ID, her 15-character user ID, a value from a custom field, or a persistent ID that only the two sides recognize (S5). In the lab, it’s the Federation ID, E10442, because you put the same value on both users. That’s still my first choice for most apps: a stable code both sides keep for the same person.

Some apps want more than a name: her country, her department, her role. Salesforce can add custom attributes to the assertion, each a key and a value taken from a field, such as the user’s country (S5). Send only what the app needs. Everything in the assertion is information about a person, travelling through her browser.

And for an app that holds something sensitive, the app can ask Salesforce to make her sign in again, even if she’s already logged in. That’s forced authentication, a ForceAuthn flag in the app’s SAML request. When Salesforce is the identity provider, it’s supported automatically, with nothing to set up in the org (S7).

OpenID Connect: the other way in

Section titled “OpenID Connect: the other way in”

Newer web and mobile apps often speak OpenID Connect instead of SAML. The idea is the same, a trusted system says who the person is, but the message is different. Instead of a SAML assertion, the app gets an ID token, which carries information about the user (S10). Chapter 9 opens one up.

Here’s the difference that surprises people. With OpenID Connect, “it’s not necessary to enable Salesforce as an identity provider” (S10). You don’t turn on the switch from module 2. You register the other app, give it the openid scope, and the app asks Salesforce who the person is. Users then “log in to the external app with their Salesforce or Experience Cloud site credentials” (S10).

OpenID Connect is built on OAuth, so it needs the next two chapters first. Chapter 8 teaches the base pattern of OAuth, and chapter 9 builds OpenID Connect with the web server flow. For now, know that it’s there, and know the one difference above.

Test knowledge. In my experience, know which way needs which setup. SAML: enable Salesforce as an identity provider, then register the app. OpenID Connect: no Enable Identity Provider; register the app with the openid scope, and it gets an ID token.

An Experience Cloud site as the identity provider

Section titled “An Experience Cloud site as the identity provider”

The people don’t have to be your staff. Partners and customers often sign in to an Experience Cloud site, with logins that live in Salesforce. When they need another app, the site itself can be the identity provider. Salesforce publishes separate identity provider metadata for each site (S1), and the issuer in the assertion can be the site’s address instead of your My Domain (S5). Chapter 14 builds sites and their logins.

Logging out everywhere

Section titled “Logging out everywhere”

One thing people ask: if Priya logs out of Salesforce, is she logged out of the other app too? Only if you set it up. Single logout works with SAML or OpenID Connect, with Salesforce as the identity provider or the service provider (S9). But Salesforce supports only front-channel single logout: the logouts happen as redirects in the same browser. “If a browser session expires, users aren’t logged out of the other apps” (S9). So don’t count on single logout to end every session. The other app’s own session length still matters.

How to choose

Section titled “How to choose”

Put the three side by side, and the choice comes down to two questions.

What does the other app speak? If it speaks SAML, use SAML. If it speaks OpenID Connect, use OpenID Connect. Many speak both. Then I’d ask which one its vendor recommends and tests the most.

Who are the people? Staff with logins in your org: your org vouches. Customers and partners with logins on a site: the site vouches. And if the people already sign in somewhere else every morning, ask whether Salesforce should be vouching at all. That’s module 6.

On the map

Section titled “On the map”

This module adds nothing new to the map’s blue cards, but it names the third card in the set: the OpenID Connect provider, still ahead, in chapter 9. The map is in module 1.

What’s next

Section titled “What’s next”

Module 6: choosing the identity provider. It’s usually a blend.

What an architect decides here

Section titled “What an architect decides here”
  • SAML or OpenID Connect for each app, by what it speaks.
  • The subject type each app expects, and the one value both sides keep for each person.
  • Which attributes go in the assertion, and no more than the app needs.
  • Forced authentication for the apps that hold something sensitive.
  • Whether single logout is worth setting up, knowing it’s front-channel only.

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.