How OAuth Works: an editable mindmap
Explore How OAuth Works as an editable mindmap. Follow color-coded branches for User consent, Redirect & code, Token exchange, Resource access, with supporting ideas and curved connections.
A mindmap of How OAuth Works, with the main ideas arranged around a central topic and connections that show how they relate.
How OAuth Works: an editable mindmap
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this mindmap
- Begin at “How OAuth Works” in the centre, then explore any branch that answers your question. The branch colors keep each group of ideas together.
- Curved lines show relationships; arrowheads appear only where one idea leads to another. Select any idea in the editor to change its text, position, or connections.
User consent
This branch brings together “User clicks “Sign in with provider””, “The consent screen is the step most real flows hide: the user chooses exactly which permissions the app may use, such as “read profile” but not “post”.”.
Redirect & code
This branch brings together “The redirect carries the client id, the requested scopes and a redirect URI. The user never hands their password to the client application.”, “Authorization server returns an authorization code to the client”.
Token exchange
This branch brings together “The code is short-lived and useless by itself. The exchange proves the client is who it claims to be by presenting its registered client secret.”, “Authorization server issues the access token”.
Resource access
This branch brings together “Access tokens expire after a short window. Long-lived sessions use a separate refresh token that can mint new access tokens without asking the user again.”, “Resource server validates the token and returns the user's data”, “User sees their data inside the app”.
Connections across the map
The user's password is given to the authorization server only: the client and resource server never see it.
Consent (the scopes) is the actual grant; the access token is that grant in machine-readable form.
The authorization code is short-lived and useless without the client secret: two factors protect the exchange.
Access tokens expire; refresh tokens quietly mint new ones without another consent screen.
The resource server's only job is validating the token, which keeps the parties decoupled.
Key relationships and takeaways
- The user's password is given to the authorization server only: the client and resource server never see it.
- Consent (the scopes) is the actual grant; the access token is that grant in machine-readable form.
- The authorization code is short-lived and useless without the client secret: two factors protect the exchange.
- Access tokens expire; refresh tokens quietly mint new ones without another consent screen.
- The resource server's only job is validating the token, which keeps the parties decoupled.
When to use this visual
- Explaining to a product team why "Sign in with Google" is safe and what the consent screen asks for.
- Choosing an OAuth flow: the authorization code flow here vs. implicit or client-credentials for other scenarios.
- Auditing where user credentials and tokens actually travel in your integration.
How it works
Start at the central topic
Rename “How OAuth Works” if you want to adapt this map to a specific project or lesson.
Develop the branches
Edit the supporting ideas, then add examples and notes where a branch needs more detail.
Connect related ideas
Draw curved connections across branches; use an arrow only when the relationship has a direction.
Frequently asked questions
What is OAuth and why does it exist?
OAuth is a delegation standard. It lets an application access a user's data on another service on the user's behalf without the application ever seeing the user's password. The user authenticates once at the authorization server and approves specific permissions (scopes); the app receives a token it can spend. That separation of concerns is exactly what the four clusters in the visual represent.
What is the difference between an authorization code and an access token?
An authorization code is a short-lived intermediate value the client receives after the user's consent; on its own it grants nothing. The client exchanges the code (along with its registered client secret) for an access token, which is the actual capability used to call the resource server. The two-step exchange is what lets the client prove its identity at the token endpoint.
Why doesn't the user give their password to the app?
Because the app only needs limited, revocable access: reading a profile, not owning an account. If the app received the password it would have full access forever, and the user could not revoke one app without changing their password everywhere. OAuth trades a password for a scoped, expiring token the user can revoke independently.
What are scopes?
Scopes are the specific permissions the user grants, such as "read email" or "write to calendar". They appear on the consent screen and are encoded into the access token. The resource server enforces them, so a token scoped to reading cannot write: least privilege is built into the protocol rather than relying on the client's good behaviour.
Edit this mindmap in QueryChart
Open this mindmap as your own editable free canvas. Move ideas, add branches, and draw new connections.