OAuth 2.0 Explained Simply: Access Tokens, Scopes and Flows
OAuth 2.0 is the industry standard for delegated authorisation. This guide explains access tokens, scopes, the four grant flows, and how JWTs fit into the picture.
ProfitTool Team
Security & Dev
What OAuth 2.0 Is
OAuth 2.0 is an authorisation framework — it lets users grant third-party applications limited access to their accounts without sharing passwords. When you click "Sign in with Google" on a website, OAuth 2.0 is what powers the delegation of access.
Key Concepts
Roles
- Resource Owner: the user
- Client: the application requesting access
- Authorisation Server: issues tokens (Google, GitHub, Auth0)
- Resource Server: the API being accessed (Google Drive API, GitHub API)
Tokens
- Access token: short-lived credential proving authorisation. Often a JWT.
- Refresh token: long-lived credential used to obtain new access tokens without re-authentication.
- ID token: (OpenID Connect extension) a JWT containing user identity claims.
Scopes
Scopes define the specific permissions being requested: read:email, write:files, openid, profile
The user sees and approves the requested scopes during the authorisation flow.
The Four Grant Types
1. Authorisation Code Flow (Recommended for Web and Mobile)
Most secure flow. The client receives an authorisation code (via redirect) and exchanges it for tokens server-side. The token exchange happens server-to-server, never in the browser.
2. Authorisation Code + PKCE
The recommended flow for public clients (SPAs, mobile apps) that cannot keep a client secret. PKCE (Proof Key for Code Exchange) adds a code verifier/challenge to prevent authorisation code interception.
3. Client Credentials Flow
Machine-to-machine. No user involved. The client authenticates with its own credentials (client_id + client_secret) to get an access token for its own resources.
4. Device Code Flow
For devices with limited input (smart TVs, CLI tools). User authorises on a secondary device.
Where JWTs Fit
Access tokens and ID tokens are commonly JWTs — they carry claims about the user and the authorised scopes, signed by the authorisation server. Resource servers validate the signature and read the claims without querying the auth server on every request.
Inspect OAuth access tokens and ID tokens with our JWT Claims Inspector.
ProfitTool Team
Security & DevWritten and maintained by the ProfitTool team. Where an article references a ProfitTool utility, the behaviour described is the behaviour of the tool on this site — you can open it and check the output yourself.
More from the Knowledge Hub
What Is a JWT? JSON Web Tokens Explained
A plain-language guide to JSON Web Tokens — what they contain, how they are structured, and where they are used in modern authentication systems.
Developer ToolsJWT Authentication vs Session Tokens: Which Should You Use?
JWTs and server-side sessions are both ways to maintain authentication state. This guide compares them on security, scalability, revocation and practical use cases.
Developer ToolsJWT Expiration Explained: exp, iat and nbf Claims
How JWT time claims work — exp, iat and nbf — plus clock skew tolerance, choosing a token lifetime, refresh-token rotation and the revocation gap.