Unit 7: Logins, MFA and tokens · Lesson 5 of 7 · 22 min
Sign in with another account
Follow an OAuth and OpenID Connect sign-in through every redirect and check its safety parameters.
mission
- You are
- The analyst reviewing a new sign-in feature.
- Situation
- The shop's next release adds Sign in with Example ID. The developers recorded every step of the flow in the lab browser for you.
- Goal
- Walk the flow and check the parameters that keep it safe.
- Hand in
- A table of the flow's steps with the state, PKCE and scope values.
OAuth as a valet key
Start at the button
Open the click step. The shop answers with a redirect to the identity provider and a short-lived state cookie.
you should see A long Location URL and a cookie holding the state value.
Read the authorize request
Open the Example ID page. Read its address parameter by parameter.
you should see client_id, redirect_uri, scope, state and a PKCE code_challenge.
defender tip state ties the answer to this browser and stops someone else's sign-in being injected. PKCE ties the code to the app that started the flow.
Back at the shop
Open the callback. Compare its state with the cookie the shop set at the start.
you should see The same state value in both places, and a code in the query string.
The exchange you never see
Open the token exchange. The shop's server swaps the code, its own secret and the PKCE verifier for tokens.
you should see Tokens travel server to server only, and the shop gives the browser its own session cookie instead.
Two redirect URIs
redirect_uri=https://*.example.com/*
Any page on any subdomain could receive the code.
redirect_uri=https://app.example.com/callback
The provider only sends codes to one registered address.
What a defender takes away
- 1OAuth hands the app a scoped key, never the user's password.
- 2Check
state, PKCE and an exact redirect URI on every flow. - 3Tokens belong on the server; the browser gets a normal session cookie.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.