OAuth 2.0 explained: delegated access without passwords

OAuth 2.0 is a standard that lets an application get limited access to your data at another service without receiving your password. Think of a hotel keycard: it opens your room and the gym, for a fixed period, and the hotel can switch it off at any time, but it is not your passport.

What OAuth 2.0 is for

Imagine a calendar app that wants to read your Google calendar, or a printing service that wants to fetch photos from a cloud drive. The old way was to hand over your password, which gave the app everything and could not be undone without changing the password. OAuth 2.0 replaces this with tokens: small, scoped, time-limited permissions issued by the service that holds your data.

The specification is RFC 6749 (2012), with the bearer token usage in RFC 6750. It is a framework rather than a single protocol, so real deployments choose from several “grant types”.

The roles

Role	What it is	Example
Resource owner	The person who owns the data	You
Client	The app that wants access	A calendar planner
Authorisation server	Authenticates you and issues tokens	The provider’s login and consent service
Resource server	The API that holds the data	The calendar API

How the authorisation code flow works

This is the flow recommended for almost everything with a user.

1. The client sends you to the authorisation server and states what it wants, for example scope=calendar.read.
2. The server authenticates you and shows a consent screen: “Planner wants to read your calendar”.
3. If you agree, the server redirects you back to the client with a one-time authorisation code.
4. The client calls the server’s token endpoint, proves who it is, and swaps the code for an access token and often a refresh token.
5. The client calls the API with the access token. The API checks the token and returns only what the scope allows.
6. When the access token expires, the client uses the refresh token to get a new one without bothering you.

A token response is short:

{
  "access_token": "SlAV32hkKG",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "8xLOxBtZp8",
  "scope": "calendar.read"
}

Other grant types exist for other situations: client credentials for server-to-server calls with no user, and the device code grant (RFC 8628) for smart TVs and consoles. The implicit grant and the resource owner password grant are no longer recommended.

Everyday examples

• “Allow this app to access your Google Drive” screens.
• A banking aggregator that reads your account data after you approve it at your bank (in the EU, open banking APIs are commonly built on OAuth 2.0 profiles).
• A smart TV that shows a code you type on your phone to link a streaming account.
• A developer tool that posts to a code-hosting service on your behalf.

Security aspects

• PKCE (RFC 7636) binds the code to the client that asked for it, so a stolen code is useless. It is recommended for every client.
• Exact redirect URIs. Registering and matching the full redirect address stops code and token theft.
• Short-lived access tokens. A bearer token works for whoever holds it, so keep lifetimes short and scopes narrow. Sender-constrained tokens such as DPoP (RFC 9449) make stolen tokens harder to use.
• Consent phishing. Attackers register harmless-looking apps and trick users into granting access. Read what a consent screen asks for, and review connected apps from time to time.
• Do not use an access token as proof of identity. A token shows that someone granted access, not who logged in. That mistake is behind many real attacks and is the reason for OpenID Connect.
• Current guidance. RFC 9700, the OAuth 2.0 Security Best Current Practice from January 2025, collects what experience has taught since 2012.

Scopes and consent in practice

A scope is a label for a permission, such as calendar.read or photos.upload. The app asks for scopes, the authorisation server shows them in plain language on the consent screen, and the access token carries only what you approved. Good providers separate read and write scopes and let you review and withdraw them later. As a user, treat a consent screen like an installation prompt: if a flashlight app asks for access to your mail, decline. As a developer, request the smallest scope that works, and ask for more only when a feature needs it.

Status and versions

OAuth 2.0 remains a published IETF standard. OAuth 2.1 is the effort to fold the security lessons into one document that would replace RFC 6749 and RFC 6750. According to the IETF datatracker it is still an Internet-Draft (revision 16, dated 3 September 2026), with a working-group milestone to send it to the IESG in December 2026. Until it is published as an RFC, “OAuth 2.1” describes a profile many libraries already follow, not a finished standard. Related extensions include PAR (RFC 9126) and the native-app guidance in RFC 8252.

How it relates to the other standards

OAuth 2.0 is the base layer. OpenID Connect adds the ID token for login. The comparison is spelled out in OpenID vs OAuth. SAML solves a related federation problem with a different, XML-based design, and the credential protocols of the EU wallet build on OAuth too.

Role in the EUDI Wallet

The EU Digital Identity Wallet uses OAuth machinery in two places. When a wallet receives an ID or attestation, OpenID4VCI uses OAuth 2.0 flows (authorisation code or pre-authorised code) to authorise the issuance. When it shows a credential to a service, OpenID4VP reuses the OAuth-style request and response pattern. For users nothing of this is visible, but it explains why developers who know OAuth find the wallet protocols familiar.