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
- 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
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
Identity layer
Parallel work at IETF and the OpenID Foundation is defining an authentication layer on top of OAuth 2.0 — the project that will become OpenID Connect — to cleanly separate authorisation (OAuth) from identity/authentication.
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 positioning itself as the foundation of Italy’s emerging API integrations: every bank, telco and public-administration project opening APIs to third parties is evaluating OAuth as the authorisation scheme.
References: RFC 6749 (October 2012). IETF. Dick Hardt editor. Authorization code, client credentials, implicit, ROPC, refresh token flows.