What is OAuth? Delegated access, explained simply

Authorisation, not authentication

This distinction is the single most important thing to understand about OAuth, and the most commonly confused. Authentication answers “who are you?” — proving your identity, typically with a password or MFA. Authorisation answers “what are you allowed to do?” — granting or denying access to a specific resource or action. OAuth is fundamentally about the second question: it was designed to let you grant an app limited access to your data on another service, not to prove your identity to that app.

That distinction matters because OAuth on its own does not tell an application who you are — only that it has been granted some scoped access. Identity was bolted on afterwards by a separate standard, OpenID Connect, built on top of OAuth, which adds a verified identity token alongside the access token. That’s the piece actually doing the work in most “Sign in with…” buttons you see today: OAuth grants access, OpenID Connect adds “and here’s who this user is”.

How it works: tokens and scopes

Instead of an app asking for and storing your password for another service — which would hand it far more power than it needs, forever — OAuth issues an access token: a piece of data that proves the app has been granted specific permissions, without exposing your credentials at all. If that token leaks, an attacker gets only the limited access it represents, and it can be revoked without touching your actual password.

Access tokens are bounded by scopes — narrow, explicit permissions such as “read your calendar” or “view your basic profile”, rather than blanket access to your entire account. A photo-printing app that only needs to read your photo library should request a scope that permits exactly that, nothing more, and you can see and approve precisely that scope before granting it.

The consent screen you already know

The familiar “App X wants to access your Google Account” screen, listing exactly what it’s asking for, is OAuth’s consent step made visible. You review the specific scopes being requested, approve or deny them, and the requesting app receives a token limited to what you approved — it never sees or stores your password for the service you’re logging into. You can typically revoke that access later from the other service’s security settings without changing your password at all.

Why OAuth beats sharing passwords

The old alternative — handing an app your actual username and password for another service — is bad on every axis: the app gets unlimited access rather than a narrow scope, it must store your password securely (or fail to), and revoking access means changing your password everywhere that credential was reused. OAuth’s scoped, revocable tokens fix all three at once, which is why it became the standard approach for connecting apps and APIs to each other across the web.

Where OAuth shows up in the cloud

OAuth underpins a large share of how modern APIs grant access to third-party applications, and cloud identity services build on it directly — Amazon Cognito, for example, uses OAuth 2.0 and OpenID Connect to manage sign-in and delegated access for applications built on AWS. It sits within the broader field of identity and access management: IAM governs identities and permissions generally, while OAuth is the specific mechanism many modern APIs use to grant one application scoped access to another on a user’s behalf.