Trust across systems

Ava opens a new application and sees a familiar choice: sign in with an account she already has. She follows it, authenticates at that account's provider, and returns to the application. The application has let another service handle the authentication.

This arrangement is federation. The service where Ava authenticates is the identity provider: an identity service, like those in What is Identity?, whose sign-in other applications rely on. It authenticates the account and supplies a result. The application decides whether to accept that result and what it means locally.

Two standards define most federated sign-in. SAML, the Security Assertion Markup Language, dates from the early 2000s, carries its messages as XML, a text format that wraps each value in named tags such as <email>[email protected]</email>, and is common for workplace applications. OpenID Connect is newer, carries compact messages built from JSON, and is common for web and mobile sign-in. It is built on OAuth, a standard for giving one application limited access to another on someone's behalf. The two standards name the application differently: it is a relying party in OpenID Connect and a service provider in SAML, although it is common for people to refer to all applications requesting authentication as service providers.

The important step happens before Ava clicks anything: the application must establish which provider it trusts and which results it will accept. A page saying that Ava signed in is not enough.

The provider needs to send evidence that the application can check. OpenID Connect uses an ID token, a token whose job is to describe a sign-in to the application rather than to grant access to an API. SAML uses an assertion. These messages identify an account in the provider's context and carry information about the authentication. Each item of information in them, such as the account's identifier or email address, is a claim in the sense from What is Identity?: a statement the provider makes about the subject.

A message needs a trustworthy source, an intended recipient, and a limited lifetime. It names its source: the provider that issued it, called its issuer, usually written as the provider's own HTTPS address, such as https://accounts.photos.example. It names its intended recipient, called its audience. And it says when it stops being valid.

This needs cryptographic protection. The provider adds a digital signature, a value computed with a secret only the provider holds. The application can check it without knowing that secret, using a matching value the provider publishes, which lets it confirm which provider produced the message and detect any change to it.

The receiving application checks the signature, checks that the issuer is the provider it expects, that the audience is this application and that the message is still within its lifetime, and checks that it answers a sign-in this application actually started. For that last check, binding the result to the sign-in attempt, the application usually sends a random value with its sign-in request and expects the same value back, so a result captured from someone else's sign-in can't be slipped into Ava's browser. Copying a name out of a message would skip the reason the message can be trusted.

The provider reports what it knows, and the application is responsible for deciding whether that evidence is acceptable.

ID token or assertion×

What the provider sends

Digital signature

Computed with a secret only the provider holds

Issuer

https://accounts.photos.example

Audience

Its intended recipient

Lifetime

When it stops being valid

Random value

Sent with its sign-in request

Claim

The account's identifier or email address

Application checks×

What the application checks

• The signature
• The issuer is the provider it expects
• The audience is this application
• Still within its lifetime
• Answers a sign-in this application actually started

Then decide whether that evidence is acceptable.

Copying a name out of a message would skip the reason the message can be trusted.

Now Ava opens a second application that trusts the same provider, such as a training portal at work that relies on her employer's sign-in. If her provider session is still usable, the provider may authenticate this request without asking for her password again. This is the experience of single sign-on, or SSO.

Each application can still create its own session. Ava's provider session, her first application's session, and her second application's session have different owners and may end at different times. Federation makes the exchange possible; SSO describes the experience that reuse can produce.

An application may require fresh authentication or a stronger method. A redirect to the provider therefore does not guarantee a silent return, even when Ava signed in there recently.

After accepting the sign-in, the application still has to choose a local account. In OpenID Connect, the message identifies the account with a subject identifier, a value the provider assigns to that account and keeps stable. The provider's issuer and the account's subject identifier belong together. Each provider assigns identifiers in its own namespace, a set of names that only has meaning inside that provider, so the same subject text from another issuer may refer to someone else.

An email address can help display or contact the account, but matching email text is not enough to merge two accounts safely. Providers may make different promises about verification, ownership can change, and an application must not let an untrusted claim choose a privileged account.

Account linking needs an explicit policy and sufficient proof that the person controls the accounts being connected. Otherwise, a convenient shortcut becomes a way to take over an existing account.

Provider A×

Provider A

Issuer

Provider A

Subject

4821

One identity in that provider's namespace.

Provider B×

Provider B

Issuer

Provider B

Subject

4821

A different identity, despite the same subject text.

A successful federated sign-in does not answer every account question. The application still needs its own access decisions. It may also need to create an account, update attributes, or remove access when someone leaves an organization.

That ongoing account lifecycle is often handled through provisioning and deprovisioning: creating and updating an application's accounts from the organization's records ahead of time, and disabling or removing them when access should end. Disabling an account at the provider can stop new sign-ins, but it does not automatically erase every application account, session, or token already issued.

Provider×

Provider

Still holds

The account

Disabling at the provider

Can stop new sign-ins

Ending access here

Disable further work sign-ins.

Applications×

Applications

Still holds

Local accounts, permissions and active sessions

Disabling at the provider

Does not automatically erase them

Ending access here

Review local accounts, permissions and active sessions.

APIs×

APIs

Still holds

Outstanding access tokens

Disabling at the provider

Does not automatically erase them

Ending access here

Consider outstanding access tokens and their lifetime.

Deprovisioning disables or removes application accounts when access should end.