OAuth Flow Simulator

Step through OAuth and OpenID Connect flows with tokens minted in your browser.

Processed locally — nothing is uploaded

A person signs in to your app and it acts on their behalf. The default for web, mobile and single-page apps alike.

An authorisation code stolen out of a redirect is useless without the verifier that only the app that started the flow knows.

Client and endpoints

Client IDRedirect URIScopeIssuerAPI audienceAccess token lifetime (seconds)

Use PKCEOpenID Connect (ask for an ID token)Confidential client (has a secret)

About OAuth Flow Simulator

Every value on screen is generated here: the verifier and its hash, the code, the tokens. The access token is a genuine JSON Web Token signed with a key this tab invented, so a decoder opens it and one altered character breaks its signature — and it authenticates nothing, because nobody is listening at either end.

The specifications are precise about what each parameter means and unhelpful about the order things happen in, which is the part people actually get stuck on. This page plays a whole exchange out: the URL the browser is sent to, what the person sees, the redirect that comes back, the direct request that trades a code for tokens, the header the API is called with, and the answer. Each leg names who is talking to whom, shows the wire text, and lists the two or three details in it that matter.

Four flows are modelled. Authorisation code with proof key for code exchange is the default for anything with a person in front of it, whether that is a server-rendered site, a mobile app or a single-page app. Client credentials covers one service calling another with nobody signed in. The device flow is for screens that cannot show a browser — a television, a set-top box, a terminal on a machine with no display. Refresh covers what happens fifteen minutes later when the access token has expired and you would rather not interrupt anyone.

The proof key matters enough to have its own switch. With it on, the first request carries only a hash, the app keeps the original value in memory, and the final exchange sends that value over a direct connection the browser never touches; a code intercepted in the middle is then worth nothing on its own. Turn it off and the page shows the older shape for comparison: the same code, but nothing anywhere proves that the party redeeming it is the party that asked for it. That is the whole argument for the extra two lines of code, and it reads better as two sequences side by side than as prose.

A separate panel does what a resource server does when the token arrives: check the signature against the issuer's key, check that the issuer is the one it trusts, check that the audience names this API and not a neighbouring one, check the expiry, and check that the granted scope covers the request. Changing a single character of the token flips the first of those to a failure while the rest stay as they were, which is a useful thing to watch once. Audience confusion — accepting a perfectly valid token that was minted for somebody else's service — is the mistake this panel exists to make visible.

What is not here is any connection to an identity provider. There is no sign-in screen, no password field, no registered redirect URI and no client secret worth the name, because all of those require a server that knows you, and this site does not have one. The endpoint names are editable so the URLs can be made to read like your own system, and everything else is a model: accurate about the shape of the messages, silent about whatever your provider does differently in the details.

Learn how this works

A Practical Guide to Everyday Developer Encoding & FormattingHow and when to use Base64, JSON formatting, hashing, JWTs, regex and cron — with free in-browser tools for each task.11 min read

Frequently asked questions

Are the tokens real?

They are real JSON Web Tokens in every respect except who will accept them. Each run generates a random signing key in the tab and signs the access token and the ID token with it using the browser's own cryptography, so they decode in any viewer, verify against that key, and stop verifying the moment a character changes. No service anywhere will accept one, because the key exists only until you reload the page.

Can I point it at my own identity provider?

No, and it would need a server on our side to do it safely. What you can do is set the issuer, audience, client id, redirect URI and scopes to the ones you use, so the requests on screen read like the ones you are about to write. Take the shape from here and the specifics from your provider's documentation, which is where the differences live.

Which flow should I be using?

If a person signs in, the authorisation code flow with a proof key, whatever the platform — the older implicit flow is deprecated and the password grant is worse. If it is one machine calling another with nobody present, client credentials. If the device cannot show a usable browser, the device flow. Refresh is not an alternative to those; it is what you add so that short access token lifetimes do not turn into repeated sign-in prompts.

Why does the ID token have no scope claim?

Because it is not for an API. The ID token tells your application who signed in and when, and its audience is your client; you verify it once and read it. The access token is for the resource server and should be treated as opaque by your app even when it happens to be readable. Sending an ID token to an API is a common and quietly broken habit.

Is anything sent to a server?

No. Everything runs locally in your browser using standard web APIs — your text, files and inputs are never uploaded to a server, so the tool works even offline once the page has loaded.

Is it free?

Completely. There is no sign-up, no account, no watermark and no usage limit. The tool is supported by unobtrusive ads, not by selling or processing your data.

Pro Tips

→Turn the proof key off and step to the exchange: the request loses the one field that ties the code to the app that started the flow. That contrast is the fastest way to explain it to someone.
→Copy the access token into the JWT decoder, change one character in the middle, and watch the signature check fail while the claims still read perfectly. Readable is not the same as trustworthy.
→Set the issuer and audience to your own names before you screenshot anything for a document; the requests then match the system your reader is working on.
→Set a short lifetime and open the refresh flow to see the 401 your client has to handle. The header names the reason, and a client that reads it refreshes instead of bouncing the person to a login screen.
→In the device flow, notice that the screen doing the signing in is never the screen you type the password on. That separation is the entire point of the extra round trip.

Common Use Cases

•Explaining to a team why a mobile app cannot keep a client secret, with the two flows side by side.
•Bringing a developer up to speed before they integrate with an identity provider next week.
•Working out which request a provider means when it complains that a parameter is missing.
•Writing documentation or a diagram, with exact request text to copy rather than retyped approximations.
•Checking your own understanding of audience and issuer validation before reviewing somebody else's API middleware.

How It Compares

Your provider's own playground runs against their real servers, which is the right place to test credentials and the wrong place to learn the sequence, since a failed attempt tells you little and every provider's console is laid out differently. Hosted debuggers ask you to paste tokens into somebody else's site, which is fine for a demo token and careless with a live one. The specifications themselves are exact and long. This sits between them: the whole sequence, editable, with tokens that behave like tokens and reach nobody.