How OAuth 2.0 works
OAuth 2.0 defines four roles. The resource owner is the user. The client is the application that wants access. The authorization server authenticates the user and issues tokens. The resource server hosts the protected data and accepts those tokens. Instead of handing its password to the client, the user approves a specific, scoped grant at the authorization server.
The most common flow is the authorization code flow: the client redirects the user to the authorization server, the user authenticates and consents, and the server returns a short-lived code that the client exchanges for an access token. The PKCE extension protects this exchange for mobile and single-page applications that cannot keep a client secret. Access tokens are deliberately short-lived, with refresh tokens used to obtain new ones without re-prompting the user.
Why OAuth 2.0 matters
Before OAuth, integrating two services meant giving one of them your password for the other, which granted unlimited access and could only be revoked by changing the password everywhere. OAuth replaced that anti-pattern with scoped, revocable, time-limited tokens. An application can be allowed to read your calendar without being able to delete your email.
OAuth 2.0 has become the foundation of the modern API economy and of modern identity itself. OpenID Connect, the dominant authentication protocol for web and mobile applications, is a thin identity layer built directly on top of OAuth 2.0. Understanding OAuth's roles, flows, and token model is therefore a prerequisite for understanding how most contemporary sign-in and API security works.
OAuth 2.0 in practice
Current best practice is straightforward: use the authorization code flow with PKCE for every interactive client, use the client credentials flow for pure machine-to-machine access, and avoid the deprecated implicit and password grants entirely. Keep access token lifetimes short, request the narrowest scopes that work, and validate tokens on every API call.
Common pitfalls include treating an access token as proof of who the user is (that is OpenID Connect's job), storing tokens where scripts can read them, and skipping redirect URI validation, which enables token theft. Monosign implements OAuth 2.0 and OpenID Connect with PKCE support, acting as the authorization server that issues and validates tokens for connected applications.