The shared-password problem
Until the early 2000s integration between applications often took place by asking the user for username/password of the third-party service. The “calendar sync” that asks for Gmail’s password, the backup tool that asks for Dropbox access. An unacceptable pattern for security (permanent token sharing, no granularity, difficult revocation).
OAuth 1.0 (RFC 5849, April 2010) introduces the concept of delegated token, but with complex HMAC signing. OAuth 2.0 is its simplified rewrite.
The release
RFC 6749 and RFC 6750 (bearer token) are published by IETF in October 2012. Editor: Dick Hardt (Microsoft). Work lasted from 2010, with contributions from Google, Facebook, Twitter, Yahoo.
Actors
- Resource Owner — the user
- Client — the application wanting to access
- Authorization Server — issues tokens (e.g. accounts.google.com)
- Resource Server — protected API (e.g. www.googleapis.com)
Flows (grant types)
- Authorization Code — standard for webapps with backend; user-agent + backend code-for-token exchange
- Implicit — for browser-only SPAs; deprecated in 2021 (OAuth 2.1) for security
- Resource Owner Password Credentials — user gives username/password to client; discouraged
- Client Credentials — M2M (machine-to-machine), only client_id + client_secret
- Refresh Token — access token renewal without re-login
- Device Code (RFC 8628, 2019) — device with limited input (Apple TV, smart TV)
Tokens
Access tokens are opaque (reference) or signed/encrypted JWT. Bearer token in HTTP header:
GET /api/me HTTP/1.1
Authorization: Bearer eyJhbGc...Scope and consent
- Scope — granularity of permissions (
read:profile,write:posts) - Consent screen — user explicitly approves permissions
OpenID Connect
OpenID Connect (OIDC) (February 2014) is an authentication layer on OAuth 2.0, adds id_token (JWT with standardised user claims), openid, profile, email scopes, UserInfo endpoint. Resolves the confusion between OAuth (authorisation) and identity (authentication).
Evolution
- OAuth 2.1 (draft 2020+) — consolidates best practices, deprecated implicit/ROPC
- PKCE (RFC 7636, 2015) — mandatory for all public clients
- Token Binding, DPoP — token binding to client
- FAPI — open finance profiles
Implementations
- Keycloak — OSS identity & access management
- Auth0, Okta, Azure AD — SaaS
- Ory Hydra, Ory Kratos — OSS cloud-native
- Spring Security OAuth, Django OAuth Toolkit, Passport-OAuth2
In the Italian context
OAuth 2.0 is the foundation of:
- SPID — Italian digital identity federation (with ad-hoc profiles)
- CIE — Electronic Identity Card (OIDC-like)
- PagoPA — API authentication
- Login with Google/Facebook/Apple — every B2C site
- B2B APIs — banks, telco, public bodies opened via scope-based OAuth
- PNRR open data — standardised APIs with OAuth
References: RFC 6749 (October 2012). IETF. Dick Hardt editor. Authorization code, client credentials, device code flows. OpenID Connect (February 2014). PKCE RFC 7636. OAuth 2.1 draft 2020+.