Delegate photo access without sharing a password

Setup

This is the first lab of the OAuth track. Later OAuth labs build on the tenant state it leaves behind.

1. In the tenant portal, open your Lab Photos tenant. For a clean start, reset the lab tenant with the Lab Photos preset (Overview > Reset tenant, then choose the preset). Reset keeps Audit and Logs by default. If you keep your existing tenant instead, confirm that OAuth > Scopes lists photos.read as common and Users lists Ava Archer ([email protected]).

2. Open Users > Ava Archer > Set password and give her a test password you use only in these labs. Keep it in your shell, not in a file.

3. Open OAuth > Clients > Token Decoder > View. It is the tenant's built-in public client, and in this lab it plays the printing application. Note its client ID and its redirect URI, which is on your tenant's own host.

4. Set the shell variables, then press Start on this page.

export ISSUER="https://tenant-<id>.beyondthelogin.dev"   # your Lab Photos issuer, from Overview, no trailing slash
export DECODER_ID="<Token Decoder client ID>"
read -rs AVA_PASSWORD   # paste Ava's test password, then press Enter

Walkthrough

1. Open $ISSUER/token-decoder in your browser. Set Scopes to photos.read only and start sign-in. Sign in as Ava on the tenant's own sign-in page. The consent page names "Token Decoder" and lists the description of photos.read. Approve.

Why it matters: Ava types her password only into the photo service's own page. The application asking for access never sees it, which is the delegated access problem the lesson starts from.

2. Read the token response the decoder shows. It has token_type: Bearer, an expires_in, scope: photos.read and no id_token. Copy the access token into your shell and decode it.

read -r TOKEN   # paste the access token
btl-lab decode "$TOKEN"

The payload shows iss (your issuer), sub (Ava's user ID), aud ($ISSUER/resource), client_id (the decoder's ID), scope and exp.

Why it matters: the token names one application, one area of access and an end time. That is a much smaller relationship than holding Ava's password, which could also delete albums or change her settings.

3. Use the token to read Ava's profile. Run it in your shell, or open it in the request console.

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

The answer is 403 with WWW-Authenticate: Bearer error="insufficient_scope".

Why it matters: whoever holds a bearer token gets only the access it represents. Reading the profile needs openid, which Ava never granted to this application.

4. Run the decoder again with Scopes openid photos.read. This time the response also has an id_token. Copy the new access token into TOKEN and repeat step 3: the answer is now 200 with {"sub": "..."}.

Why it matters: openid asks for the OpenID Connect layer on top of OAuth. The first run gave the application access to photos, but no standardized result it could use to sign Ava in to its own account system.

5. Take the access away, as the application would when Ava disconnects it. A public client identifies itself with client_id only.

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

client_id=$DECODER_ID&token=$TOKEN

The answer is 200 with {}. Repeat the UserInfo request from step 3: 401 with WWW-Authenticate: Bearer error="invalid_token".

6. Open $ISSUER/account in a private window and sign in as Ava with the same password. It works.

Why it matters: ending the application's access did not touch Ava's password, and nothing else she uses was disrupted. With a shared password, cutting off one application would have meant changing the password everywhere.

Break it

1. Check the revoked token's contents with the toolkit.

btl-lab verify "$TOKEN" --issuer "$ISSUER" --audience "$ISSUER/resource" --type at+jwt

Every check passes: the signature is valid and exp is still in the future. Yet UserInfo refused this token in step 5. A token's contents alone do not say whether the service still honors it. The Trust boundaries lab returns to this.

Check your work

Press Check my progress. In tenant Audit you can also find:

• oauth.authorize succeeded code_issued with actor Ava and client Token Decoder, followed by oauth.token succeeded.

• oidc.userinfo rejected insufficient_scope, then oidc.userinfo succeeded userinfo_served.

• oauth.revoke succeeded access_token_found.

• account.sign_in succeeded for Ava.

Logs has a summary row for oidc.userinfo rejected invalid_token with status 401.

Cleanup

Keep Ava, her password and photos.read. The next labs use them.