OAuth 2.0 shows up any time an app wants to access data “on your behalf” (Google Drive, GitHub, Microsoft, banking APIs, etc.). It’s everywhere—and it’s easy to misunderstand—because it mixes security, browser redirects, tokens, and multiple parties.
Understanding OAuth 2.0 gives you a reliable way to answer questions like: Who is trusting whom? What does this token actually allow? Which flow fits a browser vs a server? That’s the difference between “it works in the demo” and “it’s safe in production.”
OAuth 2.0 is primarily a way for a client app to obtain permission to call an API on a user’s behalf.
OAuth answers: “Can this app do X with this user’s data?” Not: “Who is the user, really?”
You’ll see these roles in almost every OAuth conversation:
People often say “OAuth login” because many systems layer authentication on top using OpenID Connect (OIDC). OAuth can enable login experiences, but OAuth alone doesn’t standardize “who the user is”—it standardizes delegated access.
A calendar app wants to read a user’s Google Calendar events without ever seeing the user’s Google password. Which description best matches what OAuth 2.0 provides here?
OAuth’s core job is delegated authorization: the client gets a token that represents permission (often scoped) to call the resource server. It’s tempting to pick the identity-assertion framing because OAuth is used in “Sign in with …” flows, but that identity layer is typically OpenID Connect. Password-sharing (even encrypted) is exactly what OAuth is designed to avoid, and account creation is a separate onboarding concern.