Identity and access mechanisms

• User / client

  A person, or the software acting for them, beginning a sign-in or access request.

  Example: You select Sign in and your browser starts the request.

• Identity service

  A system that checks identity and manages sign-in decisions.

  Example: It checks a password and may require an additional authentication factor.

• Application

  Software that carries out a task for its user.

  Example: A timetable app looks up the next bus departure.

• Authenticator

  A device or method used to prove control of an authentication factor.

  Example: A security key or an authenticator app helps verify a sign-in. Methods have different protections against phishing.

OAuth delegation

OAuth grants scoped access; it is not by itself a login protocol.

1. User / client Identity service: Consent. The user authorizes a scoped client request.
2. Identity service User / client: Code. The redirect carries a short-lived authorization code.
3. User / client Identity service: Code + PKCE. The client exchanges the code with the required verifier.
4. Identity service User / client: Access token. The authorization server issues a scoped token.
5. User / client Application: Bearer token. The resource server validates the token and operation permissions.

OpenID Connect

OIDC adds an identity layer to OAuth flows.

1. User / client Identity service: Sign in. The provider authenticates the user in a protected flow.
2. Identity service Application: ID token. The client receives an ID token through its configured OIDC flow.
3. Application User / client: Local session. Issuer, audience, signature and flow binding checks precede a session.

Passkey

The authenticator signs a challenge scoped to the relying party.

1. Identity service User / client: Challenge. The relying party creates a fresh challenge.
2. User / client Authenticator: User verification. The authenticator verifies the user under its policy.
3. Authenticator Identity service: Signed assertion. The assertion binds the challenge and relying-party context.
4. Identity service Application: Identity established. A valid assertion establishes the authenticated session.

SAML federation

A service provider validates a signed assertion and its intended recipient.

1. User / client Application: Sign in. The service provider starts a federated sign-in.
2. User / client Identity service: Authenticate. The identity provider authenticates the user.
3. Identity service Application: SAML assertion. The service provider validates signature, audience, recipient and time.
4. Application User / client: Session. The application establishes its own session.

Mutual TLS

Both peers prove control of certificate-associated private keys.

1. User / client Application: ClientHello. TLS negotiation starts.
2. Application User / client: Server proof. The client validates server certificate and handshake proof.
3. User / client Application: Client proof. The server validates client certificate and handshake proof.
4. Application User / client: Protected channel. Application authorization still applies above the channel.

Magic link

A short-lived, single-use link relies on access to the delivery inbox.

1. User / client Identity service: Request link. The user asks for a sign-in link.
2. Identity service Authenticator: Email link. The link is delivered to the registered inbox.
3. Authenticator Identity service: Redeem. The service checks expiry and consumes the token once.
4. Identity service Application: Session. A local session is established under policy.