Prove each client can use only the grant that fits

Setup

1. Set the shell variables. This lab uses several clients, so each has its own name.

export ISSUER="https://tenant-<id>.beyondthelogin.dev"
export PRINTER_ID="<lab-printer client ID>"; read -rs PRINTER_SECRET
export ORDERS_ID="<lab-print-orders client ID>"
export APP_ID="<lab-printer-app client ID>"
enc() { jq -rn --arg v "$1" '$v|@uri'; }

2. Press Start on this page.

Walkthrough

1. Compare what the tenant advertises with its Flow policy.

GET $ISSUER/.well-known/openid-configuration HTTP/1.1

grant_types_supported lists exactly the grants Flow policy allows: authorization_code, refresh_token and client_credentials after the earlier labs. response_types_supported lists code.

2. Classify the clients you have built, from OAuth > Clients, using the lesson's questions.

Why it matters: whose access it is separates the grants first. Where the client runs then decides how it uses its grant, not which grant it gets.

3. A service client cannot start a user flow. Open an authorization request for lab-print-orders.

echo "$ISSUER/oauth/authorize?response_type=code&client_id=$ORDERS_ID&redirect_uri=$(enc http://127.0.0.1:8765/callback)&scope=prints.create&state=x"

It stops on the tenant's error page: the client has no redirect URIs, so there is nowhere to return a person to.

4. A user-facing client cannot act as itself.

curl -s -u "$PRINTER_ID:$PRINTER_SECRET" -d grant_type=client_credentials "$ISSUER/oauth/token" | jq

The answer is unauthorized_client, "The tenant flow policy or this client's settings do not allow this grant type." Flow policy allows the grant, but the printer's registration does not.

5. A public client cannot use client credentials at all: curl -s -d grant_type=client_credentials -d "client_id=$APP_ID" "$ISSUER/oauth/token" | jq answers unauthorized_client, "Public clients cannot authenticate, so they cannot use this grant or endpoint."

6. A refresh token does not start access. Present one that was never issued.

curl -s -u "$PRINTER_ID:$PRINTER_SECRET" -d grant_type=refresh_token -d refresh_token=never-issued "$ISSUER/oauth/token" | jq

The answer is invalid_grant. Refresh extends an authorization the client already holds; it is never the first step.

7. Flows to avoid.

   • The password grant: curl -s -d grant_type=password -d [email protected] -d password=demo-password-not-real -d "client_id=$APP_ID" "$ISSUER/oauth/token" | jq answers unsupported_grant_type. The placeholder is not Ava's real password; never send a real one.

   • The implicit grant: in $ISSUER/token-decoder, choose response type token and start. The decoder reports unauthorized_client, because Flow policy does not allow the implicit grant.

Why it matters: each grant follows from the situation, and registration plus Flow policy make the wrong choice fail instead of quietly working.

Break it

Steps 3 to 7 are the deliberate refusals. No setting changes in this lab.

Check your work

Press Check my progress. Logs also has oauth.authorize rejected invalid_redirect_uri for step 3 and oauth.token rejected unsupported_grant_type for the password grant. Both are refused before a client is identified, so they appear only in Logs.

Cleanup

None.