Oauth Token Decoder

OAuth 2.0 is an authorization framework that enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf.

For example, it allows a website to access your Google Contacts without you ever giving that website your Google password. It solves the "password anti-pattern".

Modern flows typically involve two types of tokens:

• Access Token (OAuth): Used to access APIs (e.g., read emails, post a tweet). It proves authorization. It is meant to be read by the API server (the Resource Server), not the client app.
• ID Token (OpenID Connect): Used to log the user into the client application. It proves authentication. It is meant to be read by the client app to know who logged in.

The OAuth 2.0 specification does not require tokens to be JWTs. Tokens can be "Opaque" (just a random string of characters) where the API server must ask the Authorization Server "Is this token valid?" for every request.

However, most modern systems use JSON Web Tokens (JWTs) as Access Tokens. This allows the API server to cryptographically verify the token offline, greatly improving system performance and scalability.

Historically, Single Page Applications (SPAs) used the "Implicit Flow" to receive tokens directly in the URL hash fragment (#access_token=...). This was dangerous because the token could be logged in browser history or leaked via the Referer header.

Today, best practice requires SPAs and mobile apps to use the Authorization Code Flow with PKCE. The app receives a short-lived one-time code, which it exchanges for tokens via a secure POST request, keeping the tokens out of the URL.