OAuth identity authorization refers to the way OAuth 2.0 lets you grant an application limited access to your data on another service without handing over your password. When a photo printing site asks to read your cloud albums, or a scheduling tool asks to manage your calendar, OAuth is usually the mechanism doing the granting.
This guide focuses on the authorization side of digital identity: what OAuth delegates, how tokens and scopes work, why OAuth on its own does not prove who someone is, and how to spot and remove risky permissions. Sign-in itself, handled by OpenID Connect on top of OAuth, is covered in a separate article.
Permission, Not Proof of Identity
OAuth 2.0 answers a narrow question: may this application do this specific thing with this person’s data? It does not, by design, tell the application who the person is. That distinction confuses many newcomers, because OAuth flows often begin with a familiar sign-in page.
A useful analogy is a hotel key card. The front desk checks your identity once, then hands you a card that opens your room and the gym but not the office. The door does not know your name; it only knows the card is valid for that door. OAuth access tokens behave much the same way.
Keeping identity and authorization separate is healthy. Your identity provider confirms who you are, while OAuth grants each application only the permissions it needs. Problems arise when developers treat an authorization token as proof of identity, or when users approve broad permissions without noticing what they have delegated.
The Four Roles in OAuth 2.0
OAuth defines four roles. The resource owner is usually you, the person whose data is being shared. The resource server is the service holding that data, such as an email or file storage provider, which accepts tokens through its API, the programming interface other software uses.
The client is the application asking for access, such as a printing site or a productivity add-on. The authorization server is the component that authenticates the resource owner, shows the consent screen and issues tokens. Often the authorization server and resource server belong to the same company, but they remain logically distinct.
Seeing these roles separately helps when something goes wrong. If a client misuses access, you revoke its grant at the authorization server. If a resource server accepts tokens it should reject, that is a flaw in the service holding your data. Each role has its own security responsibilities and its own failure modes.
Tokens, Scopes and What They Grant
OAuth expresses permission through tokens and scopes. Understanding these few terms makes consent screens, security alerts and developer documentation much easier to read, because nearly every OAuth decision comes down to which token carries which scope for how long.
- Access token: a credential the client presents to the resource server to use the granted permissions.
- Scope: a label describing a specific permission, such as reading a calendar or sending email.
- Refresh token: a longer-lived credential that lets the client obtain new access tokens without asking you again.
- Authorization code: a short-lived, one-time value exchanged for tokens during the grant.
- Client ID: the public identifier of the application registered with the authorization server.
Access tokens are usually short-lived to limit damage if stolen. Refresh tokens are more powerful because they can keep access alive for long periods, which is why revoking an application’s grant matters even if you no longer use the application.
How a Delegated Authorization Grant Unfolds
The most common OAuth pattern for applications acting on behalf of a person is the authorization code grant, strengthened with an extension called PKCE. It moves through a few distinct stages, each with its own security checks.
The Request and Consent
The client redirects your browser to the authorization server, listing the scopes it wants and where to send you afterward. You sign in to the authorization server if needed, then see a consent screen naming the application and the permissions requested. Approving it creates a grant recorded against your account.
The Code Exchange
The authorization server sends your browser back to the client with a one-time authorization code. The client exchanges that code for tokens over a direct, encrypted connection. PKCE, short for Proof Key for Code Exchange, adds a secret only the genuine client knows, so an intercepted code cannot be redeemed by someone else.
Using and Renewing Access
The client calls the resource server’s API with the access token. The resource server checks that the token is valid, unexpired and carries the required scope before returning data. When the access token expires, the client uses its refresh token to obtain a new one, continuing until the grant is revoked or expires.
Why OAuth Alone Is Not a Login
An access token says that some user granted some permission to some application. It is aimed at the resource server, not at the client, and its format is not standardized for reading identity. A client that treats a valid access token as proof of who the user is can be fooled.
In one known weakness, a malicious application obtains an access token from a user who signed in to it, then presents that token to a different application that naively uses tokens for login. If the second application only checks whether the token works, the attacker is signed in as the victim there.
OpenID Connect solves this by adding an ID token, which names its intended audience and describes the authentication event. Applications that need to know who signed in should use OpenID Connect and validate the ID token. OAuth then remains in its proper role: granting limited, revocable access to data and actions.
Reading a Consent Screen Like a Security Reviewer
The consent screen is the one moment where users directly control OAuth authorization. It is easy to click approve out of habit, but a few seconds of reading can prevent long-lived access to email, files or contacts by an application that does not need it.
- Confirm the application name and publisher, and be wary of names imitating well-known brands.
- Read each requested permission and ask whether the app’s purpose needs it.
- Treat requests to read and send email, manage files or access contacts as high-risk.
- Check whether the request includes offline access, which keeps permission alive while you are away.
- Cancel if anything seems excessive, then look for an alternative or a narrower option.
Some platforms label applications as verified or unverified. Verification typically means the platform reviewed certain details about the publisher, not that the application is safe in every respect. It is one signal among several, not a guarantee.
Consent Phishing and Malicious Applications
Attackers have learned that stealing a password is not the only way into an account. In consent phishing, a victim receives a message urging them to open a document or enable a feature. The link leads to a genuine authorization server, but the application requesting access belongs to the attacker.
Because the sign-in page is real and the password never leaves the legitimate service, traditional phishing warnings may not trigger. If the victim approves the request, the malicious application receives tokens with whatever scopes were granted, often including mailbox or file access, and can keep using them even after a password change.
Defenses work at two levels. Users should treat unexpected consent requests with the same suspicion as unexpected password prompts. Organizations can restrict which applications employees may approve, require administrator review for sensitive scopes and monitor new grants. Revoking a malicious grant, not just resetting a password, is essential during cleanup.
Machine-to-Machine Access With Client Credentials
Not every OAuth grant involves a person. In the client credentials grant, an application authenticates as itself and receives a token to call another service, such as a reporting job pulling data from an internal API. No user consent screen appears, because no user is delegating anything.
These identities, often called service accounts or workload identities, are easy to forget. Their credentials may sit in configuration files for years, and their permissions tend to grow over time. A leaked client secret can give an attacker the same access as the application, without any multifactor prompt.
Treat machine identities with the same discipline as human ones. Assign each a clear owner, grant the narrowest scopes possible, store secrets in a dedicated secrets manager, prefer short-lived credentials or key-based client authentication where supported, and review them regularly. Remove service accounts whose applications have been retired.
Token Storage, Lifetimes and Revocation
Tokens are bearer credentials, meaning whoever holds one can use it. That makes storage and lifetime decisions central to OAuth security. A short-lived access token limits damage if leaked, while a refresh token needs stronger protection because it can generate new access.
Server-side applications should keep refresh tokens in encrypted storage, never in logs or browser-accessible locations. Mobile apps should use the operating system’s secure storage features. Refresh token rotation, where each use returns a new refresh token and invalidates the old one, helps detect theft when a stolen copy is replayed.
Revocation must work in practice. When a user removes an application, changes their password or leaves an organization, the authorization server should invalidate related refresh tokens. Developers should also call revocation endpoints when users disconnect an integration, rather than simply deleting tokens locally and leaving the grant active upstream.
Auditing the Apps With Access to Your Accounts
Over the years, most people approve dozens of OAuth grants and forget them. A quiz app from years ago may still be able to read a social media profile, and an abandoned productivity tool may still hold access to email. Each forgotten grant is a dormant risk.
Major account providers offer a page listing third-party applications with access, usually under security or connected apps settings. Review it every few months. Remove anything you do not recognize or no longer use, and pay special attention to applications with access to email, files, contacts or the ability to act on your behalf.
Organizations can run the same audit at scale using administrative reports of granted applications. Look for applications with broad scopes, many users or unknown publishers. Removing unnecessary grants reduces the number of outside parties holding live access to your data, which shrinks the damage any single compromise can cause.
When removing an application, also check whether it created anything that keeps working without it, such as mail forwarding rules, shared links or scheduled exports.
Building OAuth Into Applications Responsibly
Developers integrating OAuth should start with a maintained library and the authorization code grant with PKCE. Request the narrowest scopes your feature needs, and ask for additional scopes only when the user activates a feature that requires them, a pattern known as incremental authorization.
Register exact redirect addresses, protect client secrets, validate the state parameter to block forged requests, and use OpenID Connect rather than raw access tokens when you need to know who signed in. Store tokens securely, rotate refresh tokens where supported and revoke grants when users disconnect.
Users, for their part, can adopt one simple routine: read every consent screen, approve only what makes sense and audit connected applications regularly. Together, careful builders and attentive users keep OAuth identity authorization doing what it does best, granting limited and revocable access without ever sharing a password.