Skip to content
SteveTechArcSteveTechArc Courses

When It Fails

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

The question this module answers: Single sign-on worked yesterday and doesn’t today. Where do you look first, and what’s usually wrong?

First, get in

Section titled “First, get in”

When single sign-on breaks, it breaks for everyone at once. So before you look for the cause, make sure you can get in. That’s the back door from chapter 4, module 5, and module 3 of this chapter: the standard login page at https://MyDomainName.my.salesforce.com?login (S1), and an admin who logs in with a Salesforce password and MFA. If you can’t get in, you can’t fix anything.

Then look in two places

Section titled “Then look in two places”

Salesforce gives you two places to look, in this order.

  1. Login History. Every failed single sign-on login is written down, with the name of the failure. Salesforce’s advice is to start here, to tell whether it’s a problem with the assertion or with the configuration (S11). The names are the ones from chapter 4, module 6: Signature Invalid, Issuer Mismatched, Audience Invalid, Recipient Mismatched, Assertion Expired, Subject Confirmation Error, Replay Detected.
  2. The SAML Assertion Validator. In Setup, Single Sign-On Settings, there’s a SAML Assertion Validator. Paste in an assertion, plain or encoded, and click Validate. It checks the assertion against your setting and tells you what’s wrong. If a user has just failed to log in, Salesforce puts that user’s assertion in the box for you, where it can (S6).

Two things to know about the validator. It stops at some errors, so after you fix one, run it again: there may be another behind it. And it only checks the assertion. If the problem isn’t in the assertion, the validator won’t see it; go back to Login History (S6).

The usual causes

Section titled “The usual causes”

After that, it’s usually one of five things.

The clocks

Section titled “The clocks”

There are a lot of dates and times in single sign-on: when the message was made, not before, not on or after. Both sides compare them with their own clocks. I’ve seen it happen: the clocks get out of step, one side sends a message, and the other won’t accept it because the times are wrong.

Salesforce gives an assertion a window: it must arrive within 5 minutes of its timestamp, plus or minus 3 minutes (S11). So a few minutes of drift is enough. In Login History it shows as Assertion Expired, even though the assertion is brand new. The fix isn’t in Salesforce. It’s the identity provider’s servers: make sure they keep exact time, automatically, and that someone is told if they drift.

The certificate

Section titled “The certificate”

The identity provider signs every response with its private key, and Salesforce checks it with the certificate you uploaded. Certificates expire. When the identity provider’s team gets a new one, Salesforce has to get the new certificate too, or every login fails with Signature Invalid. Chapter 3’s rule applies: assume every certificate expires, and know the date. Put the identity provider’s certificate on the same calendar as your own.

A value that doesn’t match

Section titled “A value that doesn’t match”

Module 3’s pairs. Someone changes an Entity ID, a new identity provider is set up with a slightly different issuer, or an address picks up an extra slash. The error name tells you which pair: Issuer Mismatched, Audience Invalid, Recipient Mismatched. Compare the value in the assertion (the validator shows it) with the field in the setting. One of them is wrong.

A My Domain change

Section titled “A My Domain change”

This one surprises people. If you change your org’s My Domain, and so its login address, SAML single sign-on stops working (S10). Salesforce’s Entity ID and its address for answers have changed, and the identity provider still has the old ones. After the change, open each single sign-on setting, take the new values from its Endpoints section, and give them to the identity provider; for SP-initiated logins, check the login page’s authentication service in My Domain too. Salesforce’s own advice, before the change: “Double-check that at least one admin can log in without authentication features such as SSO” (S10). The back door again.

Device Activation prompts

Section titled “Device Activation prompts”

Since February 2026, a SAML login from a device or browser Salesforce doesn’t recognize has to be activated, unless the identity provider says the user signed in with a secure method (S9). So if users suddenly see an activation prompt after signing in at the identity provider, look at the authentication context in the assertion (module 4). If it says a password, the identity provider isn’t telling Salesforce about the MFA it did. That’s a fix on the identity provider’s side.

Write down what you find

Section titled “Write down what you find”

Every one of these is quicker the second time, if someone wrote it down the first. Keep a page for your single sign-on: the pairs from module 3, the certificate’s expiry date, who owns the identity provider, and how to use the back door. Chapter 16 goes much further into troubleshooting. But most single sign-on failures I’ve seen were one of these five.

The end of the chapter

Section titled “The end of the chapter”

You’ve now seen single sign-on from Salesforce’s seat: the SP-initiated flow and the IdP-initiated flow, the setting that makes them work, the value that finds the user, the relay state that gets her to her page, and what breaks.

So far, Salesforce has been the one doing the trusting. The practice sets up one of your two orgs as the service provider. Then chapter 7 turns it around: Salesforce as the identity provider, the one other apps trust. That’s where your two orgs finally connect.

What an architect decides here

Section titled “What an architect decides here”
  • The back door, tested before you need it.
  • Who looks first, and where: Login History, then the validator.
  • The identity provider’s clocks, kept exact, and watched.
  • The certificate’s expiry date, on someone’s calendar, on both sides.
  • The plan for a My Domain change, with the identity provider’s team in it.

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.