OAuth 2.0 is the standard that lets an application get limited access to a resource on a user's behalf without ever handling that user's password. Instead of sharing credentials, the user approves access at a trusted provider, and the application receives a token that grants only what was approved. If you have asked "what is OAuth" while wiring up "Sign in with Google" or a third-party API, this is the short answer: it is an authorization framework built around delegated, token-based access.
The word "authorization" in that definition matters, because the most common misunderstanding is treating OAuth as a way to log users in. It is not, on its own, a login protocol. This guide keeps the jargon out: what OAuth 2.0 is, the problem it solves, the four roles in every flow, how the main flow works, the grant types you will meet, and how OAuth differs from OpenID Connect.
OAuth 2.0 solves delegated access: letting one application act on a resource for a user without holding that user's password. Before OAuth, an app that needed your data on another service asked for your username and password, which handed it full, permanent access to everything. OAuth replaces that with a scoped, expiring token the user explicitly approves.
The classic case is connecting a calendar app to your Google account. You never give the calendar app your Google password. You approve a narrow permission, such as reading calendar events, and Google issues the app a token limited to exactly that. Revoke it later and the app loses access without you changing your password. The credential stays with the provider; the app only ever holds a token.
Every OAuth flow has four participants, and naming them makes the rest of the protocol readable. They are the resource owner, the client, the authorization server, and the resource server.
The resource owner is the user who owns the data and grants permission. The client is the application requesting access, such as a web app, a mobile app, or a background service. The authorization server authenticates the user, shows the consent screen, and issues tokens; it is the engine of the flow. The resource server is the API holding the protected data, which validates the token on each request and then allows or rejects it. In many setups one managed authorization server issues tokens for many resource servers across a product.
The authorization code flow is the recommended flow for most apps, and it keeps tokens off the browser. The user is redirected to the authorization server, authenticates there, and the app receives a short-lived one-time code. The app then exchanges that code for tokens over a secure back channel, so the tokens never travel through the address bar or page scripts.
Modern practice pairs this with PKCE, Proof Key for Code Exchange, defined in RFC 7636. PKCE adds a cryptographic challenge that binds the initial request to the token exchange, so an intercepted code is useless without the matching secret. It began as a mobile safeguard and is now the recommended default for every public client, including single-page apps. If you build one flow, build this one.
A grant type is the method a client uses to get a token, and the right one depends on the client and whether a user is present. Four cover almost every real case, and two older ones are effectively retired.
The authorization code grant with PKCE is the default for web, mobile, and single-page apps where a user signs in. The client credentials grant is for machine-to-machine access with no user, such as service-to-service calls and background jobs. The device authorization grant handles input-constrained devices like TVs and CLIs, where the user approves on a phone. Refresh tokens are not a flow but a companion that gets a new access token without forcing another sign-in. The legacy implicit and resource-owner password grants are discouraged in current guidance because they expose tokens or credentials unnecessarily, which is exactly what OAuth 2.1 formalizes.
OAuth 2.0 handles authorization; OpenID Connect handles authentication. OAuth answers "what is this application allowed to do" and issues an access token for calling APIs. It does not tell the application who just logged in. OpenID Connect is a thin layer on top of OAuth that adds that missing piece, an ID token that states who the user is.
This is why "Sign in with" buttons are built on OpenID Connect, not raw OAuth. OAuth alone can hand an app a token to read your calendar, but it was never designed to prove your identity to that app. Treating a successful OAuth authorization as proof of login is the mistake behind a whole class of security bugs. When you adopt a login provider for your own product, you are almost always adopting OpenID Connect, specified at openid.net. OAuth 2.0 itself is defined in RFC 6749. For the SaaS-specific view of flows, scopes, and mistakes, read OAuth for SaaS.
MonoCloud is an OIDC-certified identity platform, so OAuth 2.0 and OpenID Connect are its foundation rather than an add-on. It supports the authorization code flow with PKCE for user-facing apps, the client credentials grant for machine-to-machine access, the device authorization grant for input-limited devices, and refresh tokens for long-lived sessions, so you match the flow to the client without building any of it yourself.
The part worth calling out is what happens when a token is requested. MonoCloud evaluates a policy before issuing an access token, deciding whether the token may be granted and what it carries, which turns OAuth from "hand out a token" into "decide access at issuance." You can see how that works in the API Access Policies guide, or start building on MonoCloud for free.