OAuth 2.0
Delegated authorisationOAuth is how you let an app do something on your behalf without giving it your password. You approve a specific, limited permission at the provider itself, the app receives a token rather than a credential, and that token can be scoped, expired and revoked.
OAuth grants an app a scoped, revocable token instead of your password — it answers “what may this app do?”, not “who are you?”
How it works
PKCE binds the code to the app that started the flow, so an intercepted code cannot be redeemed by anyone else. The app ends up with a token limited to the scopes the user actually approved.
What OAuth 2.0 does, step by step
The app redirects to the provider naming exactly what it wants — read:files, not everything.
Authentication and consent happen on the provider’s own page; the app never handles the password.
The app exchanges the one-time code, plus its PKCE verifier, for an access token at the token endpoint.
The access token is short-lived; a refresh token renews it, and the user can revoke both at any time.
In cybersecurity
OAuth is a framework, not a finished protocol — most breaches come from implementing an optional part badly, or using a flow that should have been retired.
Wildcard or partial matching lets an attacker have the code delivered to their own site.
Not just for mobile — OAuth 2.1 makes it mandatory for confidential clients too.
Without it, an attacker can graft their own authorisation onto a victim’s session — CSRF on the callback.
Handing the app your credentials is precisely what OAuth exists to avoid.
A convincing app asking for sweeping scopes is a real attack — users approve without reading.
A valid token proves access was granted, not who the user is. That is what OIDC adds.