Beta

Create a tenant

A new tenant starts with its own users, OAuth settings, audit history and logs. You are its first Tenant Admin.
BTL Admin
Lab Beyond the Login

AUTHENTICATION METHODS · LAB

Replace a method, use a recovery code and reset a lost user

Replace Mia's authenticator in the safe order, recover with a single-use code, then act as the help desk for Ben, who lost every method.

Partly readyUses your lab tenant

The lesson

Builds on: Codes, links, and approval prompts.

New to the labs? Start with the lab toolkit and the shared cast and names every lab uses.

Partly ready. Most of this lab runs today. Steps that wait on platform features are marked, and Missing infrastructure says what they need.

  • G30 Admin session listing and kill-session

Your progress

Press Start before you begin. Only events your tenant records after that count, in the order below. Checking reads your tenant's Audit, so you need Audit read access in it.

  1. Try to remove a method with a stale sign-in

    Recorded as account.security rejected (reauthentication_required).

  2. Sign in with a recovery code

    Recorded as account.second_step succeeded (recovery_code_used).

  3. Issue a new set of recovery codes

    Recorded as account.security succeeded (codes_regenerated).

  4. Reset Ben's sign-in methods as the help desk

    Recorded as tenant.users.methods.reset succeeded about [email protected].

  5. Revoke the token Ben's application still holds

    Recorded as oauth.revoke succeeded (access_token_found) about [email protected].

Request console

Requests in this lab can be sent from this page to your tenant: open one and choose Send. Fill in the values below first. They stay in this page's memory and are gone when you leave; secrets are never stored or sent anywhere except the request you send.

Setup

  1. Complete Sign in by email link, email code and authenticator code first, so Mia has an authenticator app and recovery codes.

  2. In Authentication, set recovery codes to 10, the second step to enrolled, and make sure Passkey or security key is Optional.

  3. Give Mia a backup that does not live with her phone: in her private window sign in, open $ISSUER/account/security and add a passkey on a security key, another device, or a DevTools virtual authenticator.

  4. In Ben's private window, sign in at $ISSUER/login and set up an authenticator app at $ISSUER/account/security, so Ben has a method to lose. Then open $ISSUER/token-decoder, sign in, and keep the access token in your shell. Note the Token Decoder's client ID from OAuth > Clients.

read -rs TOKEN
export DECODER_ID="<Token Decoder client ID>"

Walkthrough

  1. Wait more than 10 minutes after Mia's last sign-in, then try to remove her authenticator app at $ISSUER/account/security. The page refuses with "Confirm it is you before changing sign-in methods."

Why it matters: a session someone borrowed must not be enough to change who can enter the account. Changing methods needs a fresh check.

  1. Replace the "old phone" in the safe order. Sign out and sign in with Mia's backup passkey, which is a fresh check and proves the backup works. Only then remove the authenticator app, and set it up again on the "new phone" by scanning the new QR code.

Why it matters: the lesson's order never leaves Mia without a working method. The tenant allows one authenticator app per user, so without a second method in advance, Mia would have had to remove the old app first.

  1. Open Mia's inbox. There is one security notification for each change.

Why it matters: a notification can reveal an unexpected change, but it does not authorize anything. The tenant still checked the fresh sign-in before each change.

  1. The "lost phone": sign out, sign in with Mia's password, and at the second step choose a recovery code. It is accepted. Sign out and try the same code again: refused.

Why it matters: a recovery code stands in for every other method, so the tenant treats it like a password. It stores only a hash, and each code works once.

  1. In $ISSUER/account/security, create a new set of recovery codes and save it. At the next sign-in, try one of the old unused codes: refused.

Why it matters: issuing a new set cancels the old one, so a printed sheet that went missing stops working the moment Mia replaces it.

  1. The help desk call. Ben has "lost every method". In the portal open Users > Ben > Reset sign-in methods and confirm.

Why it matters: support acts with defined authority, a management permission, and the decision is recorded with you as the actor. Knowing Ben's email address or answering a personal question is not part of it.

  1. Look at what the reset did. Ben's browser session is gone: his next page asks him to sign in. His authenticator app and recovery codes are removed, and he has seven days to sign in with his password and enroll again. Now call UserInfo with the token Ben's application received before the reset:

GET$ISSUER/oidc/userinfo Open in console 
GET $ISSUER/oidc/userinfo HTTP/1.1
Authorization: Bearer $TOKEN

It still answers with Ben's claims.

Why it matters: removing credentials stops future sign-ins and ends tenant sessions. Tokens already issued to applications are a separate thing, as the lesson says about sessions on a lost phone.

  1. Revoke that token as the application that holds it, then send the UserInfo request again. It is now refused with invalid_token.

curl -s -d "token=$TOKEN" -d "client_id=$DECODER_ID" "$ISSUER/oauth/revoke" -w '%{http_code}\n'

Why it matters: revocation is its own deliberate step, made by or for the client that holds the token.

Break it

  1. The stale-session change in step 1 is recorded as account.security rejected with reason reauthentication_required.

  2. The reused recovery code in step 4 and the old code in step 5 are recorded as account.second_step rejected with reason invalid_code.

Check your work

Press Check my progress. The checks follow the refused stale change, the recovery code sign-in, the new code set, Ben's reset and the revocation.

Also confirm by hand:

  • Audit shows Mia's method_removed for the authenticator app only after her passkey sign-in, then method_enrolled.

  • UserInfo answered before the revocation and refused after it.

Cleanup

  • Ben can sign in with his password during the seven-day grace period and enroll again, or stay password-only for now. The authorization labs assume he has only a password.

  • Keep Mia's new recovery codes, authenticator app and backup passkey. Remove a DevTools virtual passkey if that was her backup.

Missing infrastructure

  • G30, session listing and ending a session. Neither Mia nor the administrator can see active sessions today. With a session list in $ISSUER/account/security and in the portal, the full lab would have Mia find the lost phone's session and end it, show that its next request is refused, and have the help desk do the same for Ben, as the lesson's recovery walkthrough describes.

Back to all labs

We value your privacy

We use cookies and similar technologies to enhance your browsing experience, and analytics to understand our traffic. By clicking "Allow All", you consent to optional analytics. Cookie Policy
The Lab