OAuth
termweb devsecurityprivacy
Stands for: OAuth 2.0
A standard that lets an app access your data on another service without handling your password.
OAuth 2.0 is the "Log in with..." and "allow this app to..." flow: you authorize limited, revocable access, and the app receives a token rather than your credentials. OpenID Connect builds identity on top of it. Done right, it means one breach does not hand over your password everywhere.
The single most useful thing to know about OAuth is what it is not. It is an authorization framework, not an authentication protocol: it answers what an application is allowed to do on your behalf, not who you are. Services that used it for login had to invent their own answers to identity, which is exactly the gap OIDC was created to fill.
The problem it solves is the password antipattern. Before it, letting one service access your data at another meant handing over your credentials, giving unlimited and unrevocable access. OAuth replaced that with scoped, expiring tokens issued after you approve a specific request, so an application gets permission to read your calendar rather than the keys to your account.
The complexity that trips people up is that OAuth is a framework of several flows, and choosing wrong is a security decision rather than a style preference. Authorization code with PKCE is the modern default for interactive applications; client credentials is for machine-to-machine work with no user present; implicit is deprecated because returning tokens in a URL fragment leaked them into logs and browser history. Most OAuth vulnerabilities are not flaws in the specification but the wrong flow used confidently.
Also known as: oauth, oauth2, oidc, openid connect, authorization code