Launch a sign-in from a dashboard tile

Setup

Clients have no initiate_login_uri setting yet, and tenants have no app dashboard that sends iss, login_hint and target_link_uri (G65). The relying party's side of the lesson, refusing a result it never asked for, is real today.

1. source ~/btl-oidc.sh and run btl-lab callback before each request.

2. Once G65 exists: on lab-collage, set the login initiation endpoint to your relying party's HTTPS /signin/start address and show it on the tenant's dashboard.

Planned walkthrough

1. Sign in to $ISSUER/account as Ava. The dashboard lists lab-collage, with recent items such as the autumn catalogue album.

2. Choose that item. The browser goes to your login initiation endpoint with iss, login_hint and target_link_uri, as a GET or an automatically submitted POST.

3. Your endpoint starts a fresh code flow, as in Build a safe login initiation endpoint, and the tenant answers at once from Ava's session. The browser lands on the album.

Why it matters: the dashboard only asks the relying party to begin. Everything that comes back answers a request the relying party made, in this browser.

4. Audit shows the tile launch, then an ordinary request_started and code_issued for lab-collage.

Do today

1. The plain-link tile. With Ava signed in, open a signin URL as if a tile linked to it:

signin

The code arrives with no page in between.

Why it matters: for one provider and one front page, a link plus single sign-on is nearly enough. It stops being enough when the click should pick a provider, an account or a deep page.

2. Keep pending attempts the way a relying party does, keyed by state, and claim one exactly once:

echo '{}' > pending.json
remember() { jq --arg s "$STATE" --arg n "$NONCE" --arg v "$VERIFIER" '. + {($s): {nonce: $n, verifier: $v}}' pending.json > p.tmp && mv p.tmp pending.json; }
claim() {
  jq -e --arg s "$1" 'has($s)' pending.json > /dev/null || { echo "refused: no pending sign-in for this state"; return 1; }
  jq --arg s "$1" 'del(.[$s])' pending.json > p.tmp && mv p.tmp pending.json; echo "claimed: continue with the code"
}

3. Run a sign-in you started: signin, then remember, then open the URL. When the listener prints code and state, run claim '<state>' and then redeem '<code>'. It succeeds.

4. A result nobody asked for. Present the same callback a second time, as a dashboard that sends results straight to the redirect URI would:

claim '<state from step 3>'

refused: no pending sign-in for this state, before the code is used at all.

Why it matters: an unrequested result has nothing to match in this browser, so the relying party cannot tell whose idea it was. That is why the initiator only asks the relying party to begin, and why a careful relying party refuses such a callback.

Break it

Planned, once G65 exists: remove the login initiation endpoint from lab-collage. The tile disappears from the dashboard rather than sending a code to the redirect URI unasked.

Check your work

Today: one sign-in claimed and completed, and the replayed callback refused by your own code with no second request to the tenant. Audit shows a single oauth.token success for that code.

Once G65 exists, Audit shows the tile launch followed by request_started and code_issued for lab-collage.

Cleanup

Delete pending.json. Nothing in the tenant changed.

Missing infrastructure

• G65 (third-party initiated login). A client initiate_login_uri setting (HTTPS, validated), a tenant-user app launcher, for example on /account, that sends iss, login_hint and target_link_uri by GET or POST, and audit events for launches.