See who the downstream token says is acting, by delegation and by impersonation

Setup

These steps are real today. You need lab-printer, lab-photo-api with lab-tmp-at-storage, the credentials in the shell, and Ava's printer token AT from Try three ways to call the storage service. Get a fresh AT if it has expired.

Planned walkthrough

This walkthrough runs once your tenant supports token exchange with a configurable actor mode (G6), using the planned setup from the previous lab.

1. Delegation. With lab-photo-api's exchange policy set to record the client as actor, exchange AT for storage as in the previous lab and decode the result:

{"sub": "<Ava's ID>", "aud": "https://storage.lab.example", "client_id": "<lab-photo-api ID>", "scope": "storage.read", "act": {"sub": "<lab-photo-api ID>"}}

The storage service (btl-lab resource --port 8767 --mode introspect --audience https://storage.lab.example --read-scope storage.read) logs Ava as the subject and the photo API as the current actor.

Why it matters: sub is still Ava. client_id says which registered client asked for the token, and act says who is acting for its subject; here they are the same party. Claims inside act only identify the actor and never decide validity.

2. Impersonation, kept narrow. Switch the policy's actor mode to Impersonation (planned) with the restrictions the lesson lists: scope storage.read only, lifetime 60 seconds, this client only, and a required reason recorded with each exchange. Exchange again. The new token has no act claim, and storage logs only Ava. Audit records oauth.token succeeded token_exchanged naming both the client and Ava, with the reason.

Why it matters: at storage an impersonation token cannot be told apart from Ava. The authorization server's record is the only place the real actor appears, which is why impersonation needs a narrow scope, a short life, named clients and a reason.

3. The recipient decides what it accepts. Restart storage with --actor <lab-photo-api ID> (planned option): it accepts a token about a user only when the current actor is the photo API. The impersonation token is refused with 403; the delegation token from step 1 is allowed.

Restore: switch lab-photo-api's actor mode back to Delegation. Audit records tenant.oauth.clients.update for each change.

Why it matters: delegation is the better default wherever the recipient can understand it. It costs one claim and keeps the actor visible to the API making the decision.

Do today

1. Your tenant's own records already keep actor and subject apart. In Lab Photos, open Users > [email protected], choose Lock, then Unlock.

Restore: confirm Ava is unlocked before continuing.

Open Audit and find tenant.users.lock and tenant.users.unlock: you are the actor and Ava is the subject. That separation is what an impersonation token loses at the recipient.

2. Compare the two tokens from the previous lab. In btl-lab decode "$AT", client_id is the printer (who asked) and sub is Ava (whom it is about). In the photo API's own client credentials token, both are the photo API. These answer two of the lesson's questions; the third, who is acting now, needs act.

3. No configuration can fake an actor. In OAuth > Access token managers > lab-tmp-at-storage, try to add a claim mapping named act. The name is reserved, so the change is refused. Once token exchange exists, only the exchange itself will set act.

Check your work

There are no automated checks while this lab is planned. For Do today, look in Lab Photos' Audit for tenant.users.lock and tenant.users.unlock with Ava as subject, and for the refused manager update.

Cleanup

Confirm Ava is unlocked. Keep the token exchange setup for the next lab.

Missing infrastructure

• G6 Token exchange, with an actor mode per client and target (delegation or impersonation), impersonation restrictions with a recorded reason, and act set only by the exchange. The --actor option in step 3 is a planned addition to btl-lab resource.