OAuth 2.0 definition
OAuth 2.0 is an open authorization framework that lets an application obtain limited access to a user's resources on another service without receiving the user's password. The user approves specific permissions, and the application receives an access token for those scopes. OAuth powers features like connecting apps to Google, Microsoft or GitHub accounts.
How does OAuth 2.0 work?
OAuth involves four roles: the resource owner, usually the user; the client application requesting access; the authorization server that authenticates the user and issues tokens; and the resource server, the API holding the data. When a scheduling app wants to read your calendar, it redirects you to the provider's authorization server. You sign in there, never giving your password to the scheduling app, and approve the requested permissions, called scopes.
The authorization server redirects back with an authorization code, which the app exchanges for an access token. The app sends the token with API requests, and the resource server checks that it is valid and covers the requested scope. Access tokens are short-lived, and refresh tokens let the app obtain new ones without asking the user again.
OAuth grant types
OAuth defines several flows, called grant types, for different kinds of clients and situations. Choosing the right one is essential for security, and current best practice, captured in the OAuth 2.0 Security Best Current Practice (RFC 9700) and consolidated in the OAuth 2.1 draft, which makes PKCE mandatory, has retired some older flows. The commonly used grants are listed below.
- Authorization code with PKCE: the standard for web, mobile and single-page apps.
- Client credentials: server-to-server access without a user.
- Device authorization: for TVs and devices with limited input.
- Refresh token: obtaining new access tokens without user interaction.
- Implicit and password grants: legacy flows that should no longer be used.
OAuth vs OpenID Connect
OAuth 2.0 is designed for authorization: granting an application access to resources. It does not, by itself, tell the application who the user is. OpenID Connect (OIDC) is an identity layer built on top of OAuth that adds an ID token, usually a JSON Web Token, containing verified information about the user. Sign in with Google or Microsoft buttons use OIDC for login, while OAuth scopes control which APIs the app may call afterwards.
Common OAuth security mistakes
Many OAuth vulnerabilities come from implementation errors rather than the framework itself. Typical problems include loosely validated redirect URIs that let attackers capture authorization codes, missing state parameters that enable cross-site request forgery, storing tokens insecurely in browser storage, requesting overly broad scopes, failing to validate tokens properly on the API side, and continuing to use deprecated implicit or password flows.
Use well-maintained libraries and identity providers such as Auth0, Okta, Keycloak, Amazon Cognito or Microsoft Entra ID rather than writing OAuth from scratch, and follow current security guidance for each client type. Review token lifetimes and scopes periodically as the application grows and adds integrations.
OAuth in real applications
OAuth is everywhere: apps that post to social media accounts, accounting tools connecting to banks under open banking regulations, CI systems accessing repositories, and internal microservices calling each other with client credentials. Nexzem implements OAuth and OpenID Connect for client platforms, both as consumers of third-party APIs and as authorization servers protecting the client's own APIs.