SAML 2.0

SAML 2.0 moves the sign-in out of the application. An identity provider authenticates the user and signs an XML document stating who they are, and the service provider validates that signature and starts a local session. The application never sees a credential and never stores one.

It is unfashionable and it is durable. Twenty years of enterprise software shipped with SAML built in, and for a large share of business applications the enterprise tier still means SAML specifically. An identity strategy limited to newer protocols will meet an application it cannot connect inside the first month.

The assertion itself is an XML document, signed by the identity provider once the user has authenticated. A service provider validates that signature, evaluates the conditions scoping the assertion, and maps the attributes inside onto its own account model.

Signature validation is the part implementations get wrong, and the failures are quiet rather than obvious. XML allows one document to be read in more than a single way, so a library that validates a signature over one element while taking identity from another can be persuaded to accept a forgery. Use a maintained library, keep it current, and do not hand-roll the parsing.

• Issuer: which identity provider produced the assertion.
• Subject and NameID: the identifier a service provider stores against its local account.
• Conditions: the validity window and the audience the assertion was intended for.
• Attribute statement: whichever user attributes are released to that particular service provider.
• Signature: the cryptographic proof over the assertion, the response, or both.

SAML is the workforce standard. If a finance system, an HR platform and a ticketing tool all advertise single sign-on, the enterprise tier almost certainly means SAML on at least one of them.

New consumer-facing work rarely begins with SAML, because OIDC is less work to build into a browser or a mobile client and its tokens are easier to handle in modern stacks. In practice the choice is usually settled by what the application on the other side already supports, not by preference.

An assertion settles one question, and only for the moment it was issued: which person is authenticating. Account creation falls outside it, so does account removal, and no part of the protocol notifies a service provider that somebody has left the organization.

That is why SAML deployments accumulate orphaned accounts in every connected application unless something else handles the lifecycle. The something else is usually SCIM, and pairing the two is the difference between federation that improves security posture and federation that only improves the login experience.

SenseCrypt is a standard SAML 2.0 identity provider. What a service provider receives is an ordinary signed assertion, so the work on both sides comes down to metadata exchange and attribute mapping, as it would with any conformant IdP. This is standards-based configuration rather than installed software, which matters when the service provider is a SaaS product you do not control.

Everything distinctive happens before the assertion exists. Authentication is a live face check on an enrolled phone, with no password and no shared code anywhere in the flow, which leaves a phishing page aimed at that sign-in with no shared password to collect. Each tenant is its own issuer with its own signing certificate, and the verification key is selected by the certificate's SHA-256 fingerprint.