Follow the evidence in a real sign-in

Setup

This is the first lab of the authentication track. Later labs build on the users and settings you prepare here.

1. If your Lab Photos tenant holds leftovers from other experiments, reset it: in the tenant portal open Overview > Reset tenant and choose the Lab Photos preset. Audit and Logs are preserved by default. The preset creates Ava, Ben and Cora without passwords and the lab scopes.

2. Open Users and, for Ava, Ben and Cora, choose Set password. Give each a unique password from your password manager and keep them there. You type them into sign-in pages, never into the shell.

3. Open Authentication and confirm the default policy without changing it: Password Required, every other method Off, second step enrolled, role holders on.

4. Copy the issuer from Overview and keep it in your shell:

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

5. Open a private browser window for Ava. Each person in these labs gets their own private window or browser profile, because one browser holds one tenant session for every application.

Walkthrough

1. In Ava's window open $ISSUER/token-decoder and start a sign-in with the scopes openid profile email. The tenant's sign-in page asks for an email address and a password.

Why it matters: the email address is the identifier, the password is the credential, and the tenant is the verifier. The lesson's table of pieces maps onto this one page.

2. Enter [email protected] and a wrong password. The page says only that the email or password is incorrect.

Why it matters: the identifier matched an account, but authentication did not succeed. The answer discloses nothing more about the account.

3. Enter [email protected] with any password. Compare the message with step 2. It reads the same.

Why it matters: a sign-in page that answers differently for unknown addresses turns the identifier field into a way to test which accounts exist.

4. Sign in as Ava with her real password. The Token Decoder shows the ID token. Read sub, auth_time and amr, which is ["pwd"].

Why it matters: amr names the evidence the tenant actually checked, a knowledge factor. It says nothing about who Ava is in the real world, which is identity proofing, not authentication.

5. In the same window open $ISSUER/account. You are not asked for the password again.

Why it matters: the successful check created a session. Later pages rely on the session instead of asking for the password on every page.

6. Open $ISSUER/manage in the same window. The tenant sends Ava to /account.

Why it matters: authentication proved that this person controls Ava's account. It granted no management permission. Authorization is a separate decision, made on every request.

7. In the tenant portal open Audit and filter on the operation oauth.authorize. Find the two rejected attempts with reason invalid_credentials, then Ava's user_signed_in and code_issued.

Why it matters: the tenant recorded each step of the evidence trail and never the password. The rejected attempts carry no subject: a typed email address is a claim, so the record does not attach it to an account.

Break it

1. The wrong password in step 2 and the unknown address in step 3 are the failure cases. Both are recorded as oauth.authorize rejected with reason invalid_credentials, and both show the same message to the person at the keyboard. Nothing was weakened, so there is nothing to restore.

Check your work

Press Check my progress. The checks look for the rejected attempt, Ava's sign-in, the code and the token redemption, in that order.

Also confirm by hand:

• Ava's ID token contains "amr": ["pwd"] and an auth_time.

• Logs show the /manage request answered with reason not_permitted.

Cleanup

• Nothing to remove. Ava, Ben and Cora keep their passwords for the rest of the track.