Auth Lab
This is how your client signs in with their Google or Microsoft account, without your app ever seeing their password.
Live. Runs in your browser.
What your client sees
A real-life example: Picture a real estate agency's client portal. The person taps "Sign in with Google", confirms and comes back to the portal already signed in, and the portal never sees their password.
Under the hood
What it does, in technical terms
Walk step by step through the OAuth 2.0 sign-in flow with PKCE that Google, GitHub or Microsoft use, and generate the real keys with your browser's cryptography.
- Technologies
- oauth4webapi
- WebCrypto
- TypeScript
Architecture
1.Your app, in the browser
It creates the code_verifier, the code_challenge, the state and the nonce with WebCrypto, and builds the authorization URL with oauth4webapi.
2.Sample authorization server
It runs on the same page with real keys. It issues the code, checks PKCE on the exchange and signs the id_token.
3.id_token verification
Signature with the public key, issuer, audience, validity and nonce, the way your app's backend would do it.
By the numbers
- steps of the Authorization Code flow with PKCE
- 6
- attacks you can try and watch get rejected
- 4
The code
Decisions
- DEC-011: A Lab guided by certifications (opens in a new tab)
- DEC-017: The panel's own sign-in, with OAuth 2.0-style middleware (opens in a new tab)
Recorded in docs/DECISIONES.md (in Spanish), with their context and the alternatives ruled out.
Sign in to the portal
- Ask to sign in
- Give your permission
- Come back with a pass
- Check the pass
On the client portal
Client portal
Sign in with an account you already have, with no new password to create.
The portal doesn't see your password.
In this demo, all three buttons go to the same sample server, which runs in your browser with real keys.
On the service where your account lives
Your account's screen shows up here when you tap "Sign in with…".
Back on the portal
You come back here already signed in once you give your permission.
What if someone tries to sneak in?
Try the four tricks against your sign-in and watch the portal reject them.
Sign in to the portal first: each trick is tried against your sign-in.
Slips you a response they prepared
Changes the mark the portal kept when you asked to sign in (the state), as if the response came from somewhere else.
Sends the code without the secret
Uses a made-up secret (the verifier) to trade the code for a pass.
Swaps the email for an administrator's
Edits the pass to pose as someone else.
Uses a pass from another sign-in
Reuses a valid, properly signed pass, but from another visit.
- Prepare
- Ask for permission
- Sign in
- Back to your app
- Redeem the code
- Verify tokens
Step 1 of 6Your app prepares the request
Before sending you to sign in, your app creates four random values with your browser's cryptography and keeps them in your session.
None of them is a password. They're used later to check that each response belongs to this request and not to one copied or made up by someone else.
- Your app, without sending anything: creates the verifier, the challenge, the state and the nonce.
What your app keeps in your session
Generating values with your browser's cryptography…
Wait a moment: your browser is generating the values.
Want it for your business?
This is part of what I build in the web apps service. See what's included or get a reference estimate for your case.
Curious how it is built? Look under the hood
How it works
Each step shows what is sent, who sends it and why it’s secure.