Step-up authentication
Request higher authentication assurance (AAL2/AAL3) via acr_values in OAuth flows
Step-up authentication asks a user who is already signed in to complete an additional verification before accessing a sensitive resource. Wocha implements step-up through standard OAuth acr_values parameters and NIST-aligned ACR/AMR token claims.
When to use step-up
Use step-up when an operation requires stronger assurance than the user's current session provides:
| Scenario | Recommended ACR |
|---|---|
| View account settings | urn:wocha:aal1 (default) |
| Change password or add MFA | urn:wocha:aal2 |
| Transfer funds or delete data | urn:wocha:aal2 |
| Admin key management, privilege escalation | urn:wocha:aal3 |
| Adaptive risk trigger | Determined by risk engine |
Step-up is distinct from a full re-login. Wocha preserves the existing session where possible and elevates the authenticator assurance level (AAL) to meet the requested ACR.
Requesting ACR levels in OAuth
Pass acr_values in the authorise request. Wocha checks the current session ACR at consent time and redirects to MFA step-up when the session is insufficient.
Multiple values express preference order (first value has highest priority):
Wocha also accepts legacy shorthand values (aal1, aal2, aal3) and maps them to Wocha URNs internally.
Consent-time flow
- Client sends
acr_values=urn:wocha:aal2in the authorise request - User authenticates (if not already signed in)
- At consent, Wocha compares
currentAcragainst the requested value - If insufficient, the user is redirected to AAL2 step-up with the strongest enrolled factor
- After MFA completion, consent proceeds and tokens include the elevated
acrandamrclaims
Next.js
Protect a server action or route handler by checking the session ACR, then redirecting to step-up when needed:
For middleware-level protection:
Express
React
Gate sensitive UI and trigger step-up from the client:
For adaptive MFA, Wocha handles step-up automatically at consent — your app only needs explicit acr_values for operations that always require a specific assurance level.
ACR and AMR reference
ACR values
| Value | Level | Description |
|---|---|---|
urn:wocha:aal1 | 1 | Single-factor authentication (password, passkey, or social) |
urn:wocha:aal2 | 2 | Two-factor authentication (password + TOTP, SMS, or email OTP) |
urn:wocha:aal3 | 3 | Hardware-bound authentication (password + hardware WebAuthn key) |
Legacy values accepted for compatibility:
| Legacy | Maps to |
|---|---|
aal1 | urn:wocha:aal1 |
aal2, urn:mace:incommon:iap:silver | urn:wocha:aal2 |
aal3, urn:mace:incommon:iap:gold | urn:wocha:aal3 |
AMR values (RFC 8176)
| AMR | Authentication method |
|---|---|
pwd | Password |
otp | Time-based or email one-time password |
sms | SMS one-time password |
hwk | Hardware WebAuthn/FIDO2 key |
swk | Software passkey (platform authenticator) |
fed | Federated identity (OIDC/social) |
mfa | Multiple distinct authentication factors used |
Token claims
After successful step-up, ID and access tokens include:
Related
- Adaptive MFA — risk-based MFA policy and assessors
- MFA API — programmatic TOTP enrolment
- Passkeys — AAL3 with hardware keys