Need help with your APIs? I offer API discovery, governance & evangelism services. Explore services →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

OAuth 2.0

OAuth 2.0 is an authorization framework that allows third-party applications to securely access a user's resources (such as accounts or data) on another service without sharing passwords. It is widely used for enabling single sign-on (SSO) and providing secure, delegated access to APIs, with the following benefits. * **Secure Authorization** - OAuth 2.0 allows users to grant limited access to their data without exposing their credentials, reducing the risk of unauthorized access. * **Granular Permissions** - Applications can request specific scopes of access, such as read-only or write permissions, providing fine-grained control over data sharing. * **Token-Based Authentication** - OAuth 2.0 uses access tokens, which are temporary and revocable, reducing security risks associated with long-term credentials. * **Scalable and Flexible** - It supports a variety of client types (e.g., web apps, mobile apps, and IoT devices) and use cases, including single sign-on and third-party integrations. * **No Password Sharing** - Users authenticate with the authorization server, and the application receives a token instead of the user's password, enhancing security. * **Industry Standard** - OAuth 2.0 is widely adopted and supported by major platforms like Google, Facebook, GitHub, and Microsoft, ensuring compatibility with modern web and mobile applications. * **Refresh Tokens** - Provides a mechanism to renew access tokens without requiring the user to log in again, improving user experience and session management. OAuth 2.0 has become the industry standard for secure, token-based authorization, enabling applications to access user data without compromising privacy. It is ideal for SSO, API security, and third-party integrations, offering scalability, flexibility, and enhanced security for different types of applications. There are some complaints that OAuth 2.0 has become very broad and bloated, but it has reached mainstream adoption and will define authentication and authorization across the API landscape for many years to come. When you have wide variety of resources, with many end-users of those resources, applying OAuth 2.0 for API authentication and authorization makes sense.

OAuth 2.0, defined in RFC 6749, is the authorization framework that lets a user grant a third-party application scoped, revocable access to their resources on another service without ever handing over a password. Instead of sharing credentials, the application receives an access token from an authorization server and presents it to the API. It is the default answer to delegated access across the modern web and API economy.

  • Grant types - Authorization code (with PKCE), client credentials, and others that fit web apps, mobile apps, machine-to-machine, and agent clients.
  • Access and refresh tokens - Short-lived, revocable access tokens plus refresh tokens that renew access without re-prompting the user.
  • Scopes - Fine-grained permission strings that bound exactly what a token is allowed to do.
  • Separation of roles - Resource owner, client, authorization server, and resource server are distinct, so credentials never flow through the app.
  • Ecosystem of extensions - PKCE, token introspection, and OpenID Connect for identity layer on top of the same core.

In real API operations OAuth 2.0 is the line between a serious authorization posture and an API still shipping query-string keys. Across the sectors I score, authorization_code plus client_credentials is the mark of a provider that has thought about consent, least privilege, and revocation. The agentic turn raises the stakes: as autonomous clients act on a user’s behalf, the OAuth grant and scope model becomes the mechanism for deciding what an agent is actually allowed to touch — which is why programmatic client registration and headless token flows are now the frontier of good developer experience.

Referenced on the API Evangelist blog

Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.