Login flows

These diagrams show how a sign-in moves through the bridge. The detailed rules are in SSO, and the spec section for each step is in PROJECT.md §4.

Components

The bridge is the only SAML party the app talks to. The user's OIDC session stays at the provider. The app never sees the provider, and the provider never sees the app.

SP-initiated sign-in

The user starts at the app. The app sends an AuthnRequest.

ForceAuthn sends prompt=login instead of prompt=none. IsPassive never shows the sign-in page, and it gets a NoPassive status when there is no session.

IdP-initiated sign-in

The user starts at the bridge, from a link such as https://sso.example.test/idp/payroll. No AuthnRequest exists, so the response has no InResponseTo.

The ACS, audience, and entity ID come only from the app's stored settings. The request can't choose them. Every refusal in this flow shows the local error page, because there is no SAML request to answer.

Deciding on an AuthnRequest

Refusals go to the local page unless the ACS has already been validated. A SAML error response is sent only to a validated ACS, and only for SP-initiated logins (see SSO).

Key rotation

Rotation changes the certificate SPs must trust. The old certificate stays published until every SP has the new one.

See CLI: Rotate the signing key for the commands.