OPENID CONNECT · LAB

Sign in on one device and approve on another

Plan a kiosk client that names Ava, gets her approval on her phone and alone receives the tokens, and today run two real two-device sign-ins and compare where the session lands.

PlannedUses your lab tenant

The lesson

Separating the consumption and authentication devicesPractices A kiosk you do not own, Two devices, two jobs, Compared with device authorization

Builds on: Connecting a sign-in to an account.

New to the labs? Start with the lab toolkit and the shared cast and names every lab uses.

Planned. The core of this lab waits on platform features that are not built yet. The planned walkthrough shows exactly how it will run; Do today is a real exercise you can do now.

G32 CIBA

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.

ISSUER

Setup

CIBA is not implemented yet (G32): the backchannel authentication endpoint answers 501. Real two-device sign-ins do exist, through a passkey on a phone and through email links, and they show the split between the screen you use and the device you authenticate with from the other side.

Have a phone with a passkey-capable browser and your own inbox for Mia ($MIA_EMAIL, a plus-address such as [email protected]).
In Lab Photos, open Users and create Mia Lane with the email $MIA_EMAIL if she does not exist yet.
Once G32 exists: in OAuth > Flow policy, allow the CIBA grant, and create lab-tmp-kiosk: confidential, grant urn:openid:params:grant-type:ciba, delivery mode poll. Ava signs in to $ISSUER/account on her phone, where approval requests will appear.

Planned walkthrough

lab-tmp-kiosk sends a backchannel request naming Ava, with a binding message:

KIOSK_ID="<lab-tmp-kiosk client ID>"; read -rs KIOSK_SECRET
curl -s -u "$KIOSK_ID:$KIOSK_SECRET" "$ISSUER/oidc/backchannel_authentication" -d scope=openid --data-urlencode "[email protected]" -d binding_message=H4PX

Ava's phone shows "lab-tmp-kiosk wants to sign you in" with H4PX. She authenticates there and approves.
The kiosk polls the token endpoint and receives an ID token naming Ava and an access token. Her phone receives no tokens.

Why it matters: the consumption device gets the result, and the authentication device only ever talks to the provider. Neither sees the other's credentials.

The kiosk discards its tokens at the end of the visit. It never asked for offline_access.

Do today

Confirm the endpoint is honestly unavailable.

POST$ISSUER/oidc/backchannel_authentication Open in console

POST $ISSUER/oidc/backchannel_authentication
Content-Type: application/x-www-form-urlencoded

scope=openid

501 with temporarily_unavailable, and Logs counts oidc.ciba rejected not_implemented.

A passkey from your phone. In Authentication, note the current values, then set passkeys to Optional with passwordless sign-in allowed. Sign in to $ISSUER/account/security as Ava on your phone and add a passkey there. On your computer, run signin for lab-collage, open the URL, and choose to sign in with a passkey. The browser offers a QR code; scan it and approve on the phone. The computer gets the session, and the ID token's amr is ["swk","mfa"].

Why it matters: the screen you use and the device you authenticate with are different, and the browser's proximity check binds the two, much as the lesson wants the binding message to.

A cross-device email link. In Authentication, set sign-in by email link to Optional and allow links to be opened on another device. On your computer, open $ISSUER/login, choose an email link for $MIA_EMAIL, and open the link on your phone. The phone is now signed in as Mia, not the computer.

Why it matters: this is the opposite of CIBA. Here the device that authenticated receives the session, while in CIBA the consumption device receives the result.

Restore: turn cross-device email links off again, so a link works only in the browser that asked for it.

Compare in your notes, with the lesson's table: who started, how the person reached the approval, what the client knew beforehand, and which device ended up with the session or tokens, for the passkey, the email link and the planned kiosk.

Break it

Planned, once G32 exists: Ava declines on her phone, and the kiosk's next poll gets access_denied. The kiosk offers to start again and shows nothing of her account.

Check your work

Today: the 501 for the backchannel endpoint in Logs; in Audit, Ava's account.security method_enrolled for the passkey and a code_issued for lab-collage after the passkey sign-in; account.sign_in link_sent for Mia.

Once G32 exists, Audit shows the backchannel request accepted, Ava's approval on her device, and tokens issued to lab-tmp-kiosk.

Cleanup

Restore the authentication settings you noted in step 2.
Once G32 exists, delete lab-tmp-kiosk and remove the CIBA grant from Flow policy.

Missing infrastructure

G32 (CIBA). The backchannel authentication endpoint, the CIBA grant at the token endpoint, a delivery mode per client, an authentication-device surface for tenant users (for example an approvals page or notification on /account), and events for request, approval, denial and expiry.

Back to all labs

Create a tenant