Concepts

Each page here explains one idea that the screens and the protocol both rest on, in plain terms and without steps to follow. When a screen says a sign-in "looks unfamiliar", or a token has an assurance level, or an application "asks for a scope", the explanation is here.

It is for two readers at once. A person who wants to know why identity behaves as it does can read the account and sign-in ideas. A developer who is about to integrate should read the session, token, scope and authorization ideas first, because the guides in Build with identity assume them. Pages are independent, and each links to the ones it depends on.

Four ideas stack. An account belongs to a person and links to organizations through memberships. Signing in creates a session on identity's side, and proving yourself more strongly raises its assurance level. Applications never see the session. They receive tokens tied to it, carrying only the scopes you allowed. Whether you may do something is a separate question that a product asks identity.

account --membership--> organization   |   +-- sign in (methods, assurance) --> session  (held by identity)                                           |                    consent + scopes       v   application <------ tokens ------- tokens tied to the session        |        +-- "may this person do X?" --> identity (authorization)

I want to understand sign-in.

1. Authentication methods: the ways to prove who you are.
2. Assurance levels: how strongly each one proves it.
3. Step-up: why a sensitive action asks again.

I am about to integrate an application.

1. Sessions and tokens: what an application receives.
2. Scopes and consent: what it may ask for.
3. Authorization: why tokens carry no roles and how to ask instead.

A message on a screen confused me.

1. The unfamiliar browser check: why a sign-in was held.
2. Trusted devices: what Trusted and Recognised mean.
3. The recovery model: what protects you while you recover.

Accounts and organizations. Principals and accounts says a principal is anything that can be authenticated (a person, a service, a workload, an agent) and why the opaque subject, not the email address, identifies it. Organizations says an organization is the boundary a person belongs to and what it can decide. Memberships and invitations explains the four membership statuses and the ways to join. The personal workspace explains the organization a self-service account gets. Installations and the entry rule explains which applications may act in which organization. Single sign-on and managed accounts explains domains, sign-in connections, SCIM and accounts an organization manages.

Sessions. Sessions explains the server-side record of a sign-in. Session lifetimes gives the 12 hour idle and 14 day absolute defaults and the ranges an organization may choose within. Cookies explains that the cookie holds a reference, never your data.

Proving who you are. Assurance levels defines AAL1 to AAL3. Authentication methods lists each method with its level. Passkeys explains the key pair and why one enrolment works across products, and Synced and hardware passkeys explains the difference in what happens when a device is lost. Step-up explains the fresh confirmation and the 30 minute rule. The recovery model explains the way back in and the notices around it. Trusted devices explains how a browser is recognised. The unfamiliar browser check explains what you see, without saying how it is judged.

Languages. Languages explains the languages identity can serve, which are served only where switched on, how it picks one for a page or an email, what stays in English, and how an application asks for a language with ui_locales.

Tokens, scopes and consent. Sessions and tokens separates the two and introduces the three tokens and their lifetimes. Token families and refresh rotation explains why a refresh token is used once. Scopes and consent lists the standard scopes and the sentence shown for each. Consent explains when the Allow access screen appears, that a consent lasts until revoked, and what revoking does.

Authorization. Authorization explains why a product asks identity instead of reading a role, and the possible answers. Permissions and roles gives the vocabulary of namespaced permission names and roles. Delegation and token exchange explains how a service acts for someone with a narrower token that records who is acting. Groups, guests and custom roles explains giving authority to many people at once and the extra rules for guests.

None. Read What identity is if you want the product in two minutes first. Pages that use a standard name, such as DPoP or PKCE, define it where it first appears, and the Glossary holds the full list.

Is a session the same as a token? No. A session lives on identity and a token lives with an application. See Sessions and tokens.

How long does a session last? By default it ends after 12 hours idle or 14 days in all. See Session lifetimes.

Does a passkey count as two factors? A passkey with your device lock reaches AAL2 on its own. See Assurance levels.

Why was I asked to confirm it is me again? A sensitive action needs a second factor used in the last 30 minutes. See Step-up.

Can an application keep access after I revoke it? An access token already issued can work until it expires, at most 15 minutes. See Consent.

It does not give click-by-click steps, which are in Your account and Signing in and recovery. It does not give request shapes, which are in Build with identity and the Reference. Practical advice on choosing and keeping methods is in Security for users.