OAuth 2.0 is an authorization framework that lets users grant third-party applications access to their resources without sharing their credentials. Rather than giving an application your username and password, OAuth enables you to authorize specific, limited access through secure tokens that can be revoked at any time.
The problem OAuth solves
Before OAuth, applications that needed to access your data on another service had few good options. They might ask for your username and password directly, storing those credentials to act on your behalf. This approach created significant risks: the application had full access to your account, you couldn't revoke access without changing your password, and a breach at the application exposed your credentials for the original service.
OAuth introduced a better model. Instead of sharing credentials, you authorize the application to receive a limited access token. The token grants only the specific permissions you approved, expires after a set time, and can be revoked without affecting your underlying account.
How OAuth 2.0 works
OAuth 2.0 involves four key roles: the resource owner (you), the client (the application requesting access), the authorization server (which verifies your identity and issues tokens), and the resource server (which holds your data).
When an application needs access to your data, it redirects you to the authorization server. You authenticate directly with that server, the application never sees your credentials. The authorization server asks whether you want to grant the requested permissions. If you approve, the server issues an access token to the application.
The application uses this token to request your data from the resource server. The resource server validates the token and returns only the data the token authorizes. If you later want to revoke access, you can invalidate the token without changing your password or affecting other applications.
Authorization flows
OAuth 2.0 supports multiple authorization flows to accommodate different types of applications. The authorization code flow works well for server-side applications that can securely store credentials. The implicit flow was designed for browser-based applications, though it's being replaced by more secure alternatives. The client credentials flow handles machine-to-machine communication where no user is involved. The resource owner password credentials flow, while available, is generally discouraged because it requires the application to handle user credentials directly.
These flows provide flexibility for developers to implement OAuth appropriately for their specific application architecture while maintaining security.
Scopes and permissions
OAuth uses scopes to define what access is being granted. When you authorize an application, you see the specific permissions it's requesting, read your email, access your calendar, post on your behalf. You can often approve some permissions while denying others.
This granular control means applications receive only the access they need. A fitness app that wants to read your calendar to schedule workouts doesn't need permission to send emails on your behalf. Scopes enforce the principle of least privilege, limiting the potential damage if an application is compromised.
OAuth 2.0 in context
OAuth 2.0 is widely adopted across the technology industry. Major platforms including Google, Facebook, Microsoft, and Twitter use OAuth to enable third-party applications to access user data securely. The framework has become foundational infrastructure for modern web and mobile application development.
It's important to understand that OAuth 2.0 is specifically an authorization framework, it handles what you can access, not who you are. For authentication (verifying identity), OAuth is typically combined with OpenID Connect, which adds an identity layer on top of OAuth's authorization capabilities. Together, these protocols enable secure, privacy-preserving interactions across digital services.
Want to keep learning?
Subscribe to our blog.
