IDENTITY SECURITY · LAB

Find out what survives a password change and a methods reset

Give Cora an extra sign-in method and an app grant, then see which ones an administrator's password change ends, which ones a methods reset ends, and what needs its own removal.

Partly readyUses your lab tenant

The lesson

How attackers stay inPractices Changing the password was not enough, A second way back in, Access that outlives the session, Credentials added to applications, Making new footholds visible

Builds on: Revoking access and sharing security events.

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
G39 Telling downstream apps that access ended (beyond G17 and G28)
G40 Grant and consent inventory: list and revoke a user's app grants ("connected applications"), app approval policy, tenant-wide app block

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.

Cora enrolls an authenticator app
Recorded as account.security succeeded (method_enrolled) about [email protected].
Set a new password for Cora as administrator
Recorded as tenant.users.credentials.set succeeded.
Cora's earlier refresh token stops working
Recorded as oauth.token rejected (refresh_revoked) for lab-printer-app about [email protected].
Reset Cora's sign-in methods
Recorded as tenant.users.methods.reset succeeded.
The app's new grant still refreshes after the methods reset
Recorded as oauth.token succeeded for lab-printer-app about [email protected].
Revoke the app's refresh token
Recorded as oauth.revoke succeeded (refresh_token_found) for lab-printer-app.

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.

ISSUERCLIENT_IDREFRESH

Setup

Press Start on this page.
Sign in as Cora at $ISSUER/account/security and enroll an authenticator app.
Run the authorization code flow for lab-printer-app as Cora with offline_access, as in the Limiting what stolen access can do lab, and keep her refresh token in your shell as REFRESH.

Walkthrough

Write Cora's foothold checklist: her password, the authenticator app, her recovery codes, her browser session, the lab-printer-app grant and its refresh token, any management role, and any trusted browser. Add one row for an application credential, such as lab-print-orders' client secret.

Why it matters: an attacker who gets in usually adds several ways back within minutes, and each one ends differently. The checklist is what cleanup works from.

As Tenant Admin, set a new password for Cora in Users. Refresh her account page: the session has ended. Try her refresh token.

curl -s -d grant_type=refresh_token -d client_id="$CLIENT_ID" --data-urlencode refresh_token="$REFRESH" "$ISSUER/oauth/token" | jq .

Why it matters: your tenant ends sessions, outstanding codes, tokens and remembered consent when an administrator sets a password, so the refresh is refused. The lesson warns that providers differ here; you have now checked yours instead of assuming.

Why it matters: the password changed, but the method enrolled yesterday is still a way in. If an attacker had enrolled it, they would still be able to pass the second step the next time they learn a password.

Run the lab-printer-app flow for Cora again. The consent screen appears, because her earlier approval was forgotten. Approve it and keep the new refresh token in REFRESH.

As Tenant Admin, reset Cora's sign-in methods in Users. Her authenticator app and recovery codes are gone and her sessions have ended. Now refresh with REFRESH.

RESPONSE=$(curl -s -d grant_type=refresh_token -d client_id="$CLIENT_ID" --data-urlencode refresh_token="$REFRESH" "$ISSUER/oauth/token")
echo "$RESPONSE" | jq '{scope, expires_in, refresh: (.refresh_token != null)}'
REFRESH=$(echo "$RESPONSE" | jq -r .refresh_token)

Why it matters: the refresh works. A methods reset ends sign-ins, not the grants an app already holds. This is the lesson's "access that outlives the session": the app never needed Cora's methods.

End the grant by revoking the refresh token as lab-printer-app.

POST$ISSUER/oauth/revoke Open in console

POST $ISSUER/oauth/revoke
Content-Type: application/x-www-form-urlencoded

token=$REFRESH&token_type_hint=refresh_token&client_id=$CLIENT_ID

Why it matters: each removal ended a different foothold. Only all of them together, done at the same time, leave nothing behind, which is the order the Containing and recovering lab practices.

In OAuth > Clients, open lab-print-orders (or any confidential client) and note who could rotate or add its secret: anyone holding the permission to rotate client credentials. In Audit, source OAuth management, find any tenant.oauth.credentials.rotate events and who made them.

Why it matters: an application credential is independent of every person. Resetting Cora, or even deleting her, does nothing to it, so an unexpected credential change on a client is a foothold worth an alert.

Break it

As Cora, who holds no management role, open $ISSUER/manage. She is sent back to her account page. A footholds checklist starts from what an account can change; Cora's can change only her own sign-in methods and profile. Nothing was changed, so there is nothing to restore.

Check your work

Check my progress confirms Cora's enrollment, the password change, the refused old refresh token, the methods reset, the grant that survived it, and the revocation.
Your checklist marks, for each foothold, whether the password change, the methods reset, or its own removal ended it.

Cleanup

Clear the shell: unset REFRESH RESPONSE.
Store Cora's new password with read -rs CORA_PASSWORD. She enrolls methods again at her next sign-in if the policy asks.

Missing infrastructure

G40: there is no list of Cora's app grants with their scopes and last use, and no way for an administrator to revoke one grant. You revoked it here only because you held the client's refresh token. Once it exists, the lab will list Cora's grants in Users and revoke the lab-printer-app grant from the portal.
G30: there is no list of Cora's sessions to review before and after each step. Once it exists, the lab will read the session list after each action.
G39: applications that signed Cora in keep their own sessions after every step here. Mail rules and app passwords are context only: the tenant has neither.

Back to all labs

Create a tenant