Inventory every path into Ava's account

Setup

This is the first lab of the Identity security track. It prepares the people the rest of the track reuses.

1. In the tenant portal for Lab Photos, open Overview > Reset tenant and reset the lab tenant with the Lab Photos preset. Keep the default that preserves Audit and Logs. The preset creates Ava, Ben and Cora without passwords.

2. Press Start on this page after the reset, so the checks only count what you do next.

3. Set your shell variables. Your issuer is shown in Overview.

export ISSUER="https://tenant-<your-tenant-id>.beyondthelogin.dev"
btl-lab env security

Walkthrough

1. In Authentication, keep Password set to Required. Set Authenticator app and Passkey or security key to Optional, keep Passwordless on for passkeys, and keep Second step on enrolled. Save.

Why it matters: each method you turn on is a separate path into every account. The lesson's table of what an attacker can obtain starts here: credentials are the first row.

2. In Users, set an administrator password for Ava, Ben and Cora. Store Ava's in your shell so it never lands in a file.

read -rs AVA_PASSWORD

3. Sign in as Ava at $ISSUER/login, open $ISSUER/account/security and enroll an authenticator app and a passkey.

Why it matters: Ava now has a strong method she uses every day, but the password is still there. The lesson's point is that the weakest path decides, not the method the owner prefers.

4. Fetch the tenant's discovery document and note every endpoint that hands out a credential: the authorization, token and UserInfo endpoints, and grant_types_supported.

GET $ISSUER/.well-known/openid-configuration

Why it matters: an endpoint that issues tokens is a door. Each grant type is a different way to end up holding a token that acts for Ava or for a client.

5. Back on $ISSUER/account/security, list what Ava can use to sign in: her password, the passkey, the authenticator app as a second step, her recovery codes and any trusted browsers.

Why it matters: recovery codes and a remembered browser are paths too. A remembered browser skips the second step, much like the stolen session in the lesson's table skips the whole sign-in.

6. In the portal, open Users and look at Ava's row. Note that an administrator can reset her sign-in methods and set her password. Then open Roles and OAuth > Clients and note any management role Ava holds and which clients she could approve.

Why it matters: an administrator's reset replaces Ava's methods entirely. That is the help desk path from the Cedar timeline. What lies beyond Ava's account (roles, approved apps) decides how much each path is worth defending.

7. Write the inventory as a table with four columns: path, what it requires, what limits it, and your rank. Include at least: password, passkey, authenticator app, recovery codes, trusted browser, existing session, an app Ava approves, an administrator reset, and the tenant's signing keys.

Why it matters: the lesson says defending an account starts by counting its paths. Ranking them shows that the passkey is not the account's strength while the password remains.

Break it

1. Sign out and open $ISSUER/login again. Password sign-in is still offered next to the passkey. Adding a stronger method did not remove the weaker one. Nothing was weakened here; the Getting around MFA lab closes this path with policy.

Check your work

• Check my progress confirms the policy change, the passwords, Ava's sign-in and her two enrollments.

• In Audit, source User directory, find tenant.users.credentials.set for each person and tenant.authentication.update for the policy.

• In Audit, source Protocol activity, find Ava's account.sign_in and the account.security events with reason method_enrolled.

• Your ranked table names at least nine paths and what limits each one.

Cleanup

• Keep Ava, Ben and Cora, their passwords and Ava's methods. Later labs in this track use them.