OAuth 2.0 is an authorization standard that lets one app access your data in another service without ever seeing your password. Below you’ll find how the OAuth 2.0 flow works step by step, what tokens and scopes are, and which grant types are safe.
What is OAuth 2.0 used for?
OAuth 2.0 (often written OAuth2) is used for delegated access: you let an app act for you in another service, within limits you approve yourself.
Imagine an online photo printing service that needs access to pictures stored in your cloud drive. Without OAuth, you’d have to give the printing service your drive password, potentially giving it access to all your files and settings.
With OAuth, the printing service can request read-only access to your photos instead. You approve that request on the drive’s own login page, and the printing service receives a token that only works for that purpose. The same mechanism is used when a CI service pushes code to your GitHub repository, a calendar app reads your Google Calendar, or a dashboard pulls data from a third-party API.
Who takes part in an OAuth 2.0 flow?
The RFC 6749 specification defines four roles:
| Role | What it is | In the photo example |
|---|---|---|
| Resource owner | The user who owns the data | You |
| Client | The app that wants access | The printing service |
| Authorization server | Logs the user in, asks for consent, issues tokens | The drive’s login and consent page |
| Resource server | The API that holds the data | The drive’s photo API |
At Google or GitHub, the authorization server and the API belong to one company, but they’re still separate components. OAuth 1.0 treated them as one “service provider”, and you’ll still see the older terms in many tutorials. The data itself – your photos, files or profile – is called the protected resource, and the token is what the client presents to the service provider instead of your password.
How does the OAuth 2.0 authorization code flow work?
The authorization code flow with PKCE is the standard for any app with a user in front of it.
- You click “Connect” in the client app. The app creates a random secret (code_verifier) and its hash (code_challenge).
- The app redirects your browser to the authorization server with its client_id, redirect_uri, the scopes it wants, a random state value, and the code_challenge.
- You log in on the authorization server’s page and approve the requested permissions.
- The authorization server sends you back to the redirect_uri with a one-time authorization code.
- The client’s backend sends the code and the original code_verifier straight to the authorization server.
- The server checks that the verifier matches the challenge and returns an access token, often with a refresh token.
- The client calls the API with the header Authorization: Bearer <access_token> and gets the data.
This is what the request in step 2 looks like:
https://auth.example.com/authorize?response_type=code
&client_id=photo-printer
&redirect_uri=https://printer.example/callback
&scope=photos.read
&state=af0ifjsldkj
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256What are access tokens and refresh tokens?
An access token is the key the client shows to the API; it’s a bearer token, so whoever holds it can use it. That’s why it should only travel over HTTPS and expire quickly; Google’s access tokens, for example, are valid for one hour.
A refresh token lives longer and is used only with the authorization server, to get a new access token without asking you again. The client should keep it on the server side. Many providers rotate refresh tokens, as each use returns a new one and invalidates the old.
What are OAuth scopes?
Scopes define what a token is allowed to do. Some real examples include:
- GitHub read:user: read your profile data
- GitHub repo: full access to your public and private repositories
- Google https://www.googleapis.com/auth/drive.readonly: view, but not edit, files in Google Drive
Which OAuth 2.0 grant types should you use today?
| Grant type | Use it for | Status |
|---|---|---|
| Authorization code + PKCE | Web, mobile and single-page apps with a user | Recommended |
| Client credentials | Server-to-server calls with no user, e.g. a cron job | Recommended |
| Device authorization (RFC 8628) | TVs, CLI tools, devices without a browser | Recommended |
| Refresh token | Renewing access tokens | Recommended, with rotation for public clients |
| Implicit | Old single-page apps | Deprecated |
| Resource owner password | Apps that collect the user’s password | Deprecated |
RFC 9700, the OAuth 2.0 Security Best Current Practice published in January 2025, says the implicit grant should not be used, and the password grant must not be used. OAuth 2.1, still an IETF draft in 2026, puts these rules into one document: PKCE for every authorization code client and no implicit or password grant.
How do you run your own OAuth server on a VPS?
If you build or self-host apps, you don’t have to rely on Google or GitHub as the authorization server. Keycloak and Authentik are open-source identity providers that run in Docker and give your internal tools single sign-on over OAuth 2.0 and OpenID Connect. What should you do on day one?
- Serve the authorization server over HTTPS only.
- Register exact redirect URIs, without wildcards.
- Keep client secrets in environment variables, never in the repository.
- Sync the server clock with NTP, since token expiry checks depend on it.
Our Docker VPS is ready for containers from the start. Once you’ve connected to it over SSH, it should take one docker compose up to deploy an identity provider.
Need support? You can always contact us at [email protected].
