See what the browser carries in the code flow, and what it does not

Setup

The eight labs in this section grow one client, lab-printer, from its first request to a fully checked exchange.

1. Set the shell variables for lab-printer (from the Public and confidential clients lab), then press Start on this page.

export ISSUER="https://tenant-<id>.beyondthelogin.dev"
export CLIENT_ID="<lab-printer client ID>"
read -rs CLIENT_SECRET
export REDIRECT_URI="https://beyondthelogin.dev/lab/callback/"   # or http://127.0.0.1:8765/callback with btl-lab callback running
enc() { jq -rn --arg v "$1" '$v|@uri'; }

Walkthrough

1. Build the printer's request. It includes openid so that the UserInfo endpoint can stand in for the photo API.

eval "$(btl-lab pkce)"; eval "$(btl-lab state)"
echo "$ISSUER/oauth/authorize?response_type=code&client_id=$CLIENT_ID&redirect_uri=$(enc "$REDIRECT_URI")&scope=$(enc 'openid photos.read')&state=$STATE&code_challenge=$CHALLENGE&code_challenge_method=S256"

2. Open it, sign in as Ava and approve. The callback shows code, state and iss. Copy the code: read -r CODE.

Why it matters: everything that crossed the browser holds a short-lived code. No token was placed in a URL, so none can leak through history, logs or a referrer.

3. Offer the code to the API as if it were a token.

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

The answer is 401 with WWW-Authenticate: Bearer error="invalid_token".

Why it matters: the code is an intermediate credential. The API does not accept it.

4. Try the exchange from somewhere that has the code but not the printer's secret: a second terminal, as if the code had been copied out of the browser.

curl -s -i -d grant_type=authorization_code -d "code=$CODE" --data-urlencode "redirect_uri=$REDIRECT_URI" \
  -d "code_verifier=$VERIFIER" -d "client_id=$CLIENT_ID" "$ISSUER/oauth/token"

The answer is 401 invalid_client. The code is still unused.

5. Exchange it as the printer's backend, with its credentials and its PKCE verifier.

curl -s -i -u "$CLIENT_ID:$CLIENT_SECRET" -d grant_type=authorization_code -d "code=$CODE" \
  --data-urlencode "redirect_uri=$REDIRECT_URI" -d "code_verifier=$VERIFIER" "$ISSUER/oauth/token"

The answer is 200 with Cache-Control: no-store and a JSON body holding access_token, token_type, expires_in, scope and id_token. Copy the access token: read -r TOKEN.

Why it matters: the token arrives in the body of a direct response. That request is where the server could check the printer's secret and its PKCE verifier, two checks a token sent back through the browser would allow neither of.

6. Call the API with the token: repeat step 3 with $TOKEN instead of $CODE. The answer is 200 with Ava's sub.

7. Search your browser history for the callback address. The entry holds the code; no access token appears anywhere in history.

Break it

1. Ask for the token to come straight back through the browser instead.

echo "$ISSUER/oauth/authorize?response_type=token&client_id=$CLIENT_ID&redirect_uri=$(enc "$REDIRECT_URI")&scope=photos.read&state=$STATE"

The callback carries error=unauthorized_client, state and iss. Neither the tenant's flow policy nor the printer's registration allows a token response, which is the safe default the lesson argues for.

Check your work

Press Check my progress. Logs also has a summary row for oidc.userinfo rejected invalid_token with status 401: the code offered as a token.

Cleanup

None. Keep the shell variables for the next lab.