How identity works, end to end

Who is involved in a TDACorp Identity sign-in, what runs where, the steps of one sign-in, how access is decided, and what is built or Planned.

On this page

This page follows one person signing in to a TDACorp product, and names every part that takes a step. Terms in bold are defined in the Glossary.

Who is involved#

Who	Role
A person	Owns an account and signs in with a browser.
An application	A TDACorp product, called a client when it signs people in. It asks identity who the person is and never sees their password or passkey.
A service	A program that calls another program's API. It signs in as itself, with no person present.
An administrator	Manages organizations, clients and users.

What runs where#

Identity is one service. It draws every page a person sees (sign-in, registration, recovery, consent, the account area and the trust pages) and answers the protocol and account APIs from the same address, so the browser always talks to one origin. You do not need to know more about how it is built to use it.

What identity stores, and for how long, is in Privacy and Retention and deletion. The generated API reference lists the routes an integrator may call.

The application sends a pushed authorization request. The application posts the details of the sign-in directly to identity's /par endpoint (PAR, RFC 9126) and gets back a short reference. PAR is mandatory: the browser never carries the request details. The reference is valid for 60 seconds and works once.
The browser is sent to identity. The application redirects the browser to /authorize with only its client id and that reference. Identity looks up the stored request.
The person proves who they are, unless they already have a session. See the next section.
The person consents, if the application is third party. An application that TDACorp ships itself skips this screen. A third-party application shows a consent screen listing what it asks for. See Scopes and consent.
Identity returns a code. The browser goes back to the application's registered address with a single-use authorization code, valid for 60 seconds. The application proves it started the sign-in with PKCE (RFC 7636): it sends a secret that matches a hash it gave in step 1.
The application exchanges the code for tokens at /token. For most applications the tokens are bound to a key the application holds, using DPoP (RFC 9449), so a stolen token is useless without that key.
The application signs the person in on its own side, and later presents the access token to its own API or refreshes it.

DPoP is required by default for every client that is not a service and that can hold an authorization code or a refresh token. Only a first-party web client may receive tokens that are not bound to a key. What the tokens contain and how long they live is in Sessions and tokens. How an application implements the steps is in Build with identity.

Note

Request details never travel through the browser, and an application never holds a person's credentials. Those two properties come from PAR and from the sign-in happening on identity's own pages.

How people prove who they are#

Identity supports several ways to sign in. Passkeys come first and are the recommended method; see Passkeys.

A passkey, the recommended method.
A password, followed by a second step where the account has one: an authenticator app code, a passkey, or a recovery code. Every account has a password. A person who lost their only passkey can use an emailed code in its place, at a lower assurance level than the passkey (flag login_email_fallback).
An email link.
An external OIDC or GitHub account, where an administrator has configured that provider.
Your organization's single sign-on connection (SAML or OIDC), where the organization has set one up. It is behind the flag tenant_connections, which is OFF by default. An organization can also require it (flag sso_enforcement, OFF by default), and then a sign-in without it is sent to the connection or, at the token endpoint, answered with an RFC 9470 insufficient_user_authentication challenge.

Which methods are offered can depend on your organization, so the sign-in page is the source of truth for a given site. After a password sign-in, identity can offer to add a passkey, and an account that has no password is asked to choose one before the sign-in completes. If someone loses access, recovery runs through a link sent to a verified email address, and notices let the real owner cancel a recovery they did not start. The steps for people are in Your account.

How access is decided#

A token says who the person is and which application it was issued to. It does not say what they may do. When a product needs to know whether a person may perform an action, it asks identity's authorization API, which decides from the person's role assignments and grants in that organization. There is no roles claim in any token. See Authorization.

What is built and what is not#

The sign-in, account area, OIDC provider and authorization API above are built. SCIM 2.0 provisioning of users and groups is built but switched off: it is behind the flag scim, which is OFF by default. These are Planned or not offered:

Planned

Device Bound Session Credentials, which would tie a session to a key in the browser's hardware, are described in the specification and have no code yet.