Assurance levels
What AAL1, AAL2 and AAL3 mean in plain language, which sign-ins reach each, and how applications ask for and read a level.
On this page
An assurance level says how strongly a sign-in proved who you are. It is a number from 1 to 3, called AAL in the NIST SP 800-63B guidance that identity follows. A higher number means the sign-in is harder to fake or steal.
The level matters because not every action deserves the same trust. Reading a page is not the same as changing how an account is protected. A level lets an application, or an organization, say what it needs.
The three levels#
| Level | In plain language | Reached by |
|---|---|---|
| AAL1 | One proof. Better than nothing, but a single stolen secret is enough. | A password alone. An emailed sign-in link or code. A linked account without a second factor from the provider. |
| AAL2 | Two things at once, or one that cannot be stolen by tricking you. | A passkey with your device lock. A password plus an authenticator app code. A linked account where the provider reports a second factor. |
| AAL3 | The strongest: a key that cannot leave a verified hardware device. | Not reachable today. Status: Planned. |
Two notes on the table.
-
A passkey reaches AAL2 on its own. Identity requires the device to check you (fingerprint, face, PIN or a security key) every time a passkey is used, so a passkey already combines "something you have" and "something you are or know". See Passkeys.
-
The extra steps stay at AAL1. A password typed after an emailed link, a password typed after a linked-account sign-in, and an emailed code typed after a password are optional extra checks. They add a check. They do not raise the level, and the sign-in page says so: This is an extra step you turned on. It adds a check, but it does not make your sign-in two-factor.
-
A limited session is AAL1. A correct password always signs you in. On a sign-in that looks unusual, an account with a passkey or an authenticator app is offered Continue with my password only (limited session), and the session it opens is AAL1 with
acraal1. An application that asks foraal2inacr_values, an organization with a floor of 2, and an account that holds a second factor and wants an age-gated action all still need the second factor, and the limited session does not satisfy them.
Why AAL3 is Planned#
AAL3 needs a key that is not exportable and a device whose make has been verified, a check called attestation. Identity does not verify attestation yet. No passkey is recorded as verified, so no sign-in reaches level 3 today. See Synced and hardware passkeys.
Where the level lives#
- A session has a level, set when it is created from the methods used. See Sessions.
- A step-up can raise the level for a short window. The level a session currently has is the higher of its own and any live step-up's. When the window closes, the level falls back. See Step-up.
- A recovery session is at AAL1 and is limited to the security page until you re-enrol a method. See The recovery model.
How an application asks for a level#
An application can ask for a level when it starts a sign-in, with the standard OpenID Connect parameters.
| Parameter | What it asks for |
|---|---|
acr_values | A minimum level. The accepted values are aal1, aal2 and aal3. |
max_age | That your sign-in is no older than this many seconds. A session that is older is asked to sign in again, or only for a fresh second factor when acr_values asks for aal2 or more. |
prompt=login | A fresh sign-in, whatever the session holds. |
Identity checks them in this order: prompt=login, then max_age, then acr_values. If the session's level is below what was asked, the person is sent to confirm with a stronger method, which is a step-up. If the application sent prompt=none, no page can be shown, so the answer is the error login_required, and the application retries without prompt=none. The discovery document lists the accepted values under acr_values_supported.
How an application reads the level#
The level comes back in the tokens as two claims.
| Claim | Meaning |
|---|---|
acr | The level reached, as aal1, aal2 or aal3. |
amr | The methods used, as short codes. See Authentication methods. |
The ID token and the access token carry both. An access token from a refresh reports the session's level at the time of the refresh. An application that needs level 2 should check acr itself and not assume that asking for it guaranteed it. A token obtained by exchange or by client credentials carries no acr, because there was no person signing in at that moment. See Delegation and token exchange.
The time of the sign-in is carried as auth_time. It stays the original sign-in time even after a step-up. Switching organization in the account area opens a new session but gives it the auth_time of the session it came from, and does not carry that session's step-up with it.
How an organization sets a floor#
An organization can require a minimum level, 1 to 3, for sign-ins to it. When an application sends someone to sign in to that organization, identity treats the floor as if the application had asked for it with acr_values. A person whose session is below the floor must confirm again. If the organization has a parent, the floor in force is the strictest of its own and its ancestors'. See Organizations.
An organization can also require a recent single sign-on sign-in. When it does, a token request for that organization from a session without one is answered with the error insufficient_user_authentication, carrying acr_values and max_age so the application can send the person back to sign in again. This is the RFC 9470 step-up challenge. It applies only while the sso_enforcement flag is on, and the flag defaults OFF. The value in acr_values is aal1, because the requirement is a fresh single sign-on sign-in, not a higher level.