You clicked a button that says “Log in with Google.” You gave a third-party app access to your calendar without typing your Google password. Behind that simple click, OAuth is working. OAuth enables secure, token-based authorization between services. It keeps your credentials private while granting controlled access to your data. OAuth is everywhere. Understanding how it works helps you implement it securely.
What Is OAuth?
OAuth (Open Authorization) is an open standard authorization framework for token-based authorization on the internet. OAuth enables an end user’s account information to be used by third-party services without exposing the user’s account credentials to the third party. It acts as an intermediary on behalf of the end user, providing the third-party service with an access token that authorizes specific account information to be shared. OAuth is primarily designed for authorization, not authentication. It grants access to resources, not identity verification.
OAuth 1.0 vs OAuth 2.0
OAuth 1.0 was first released in 2007 as an authorization method for the Twitter API. In 2010, the IETF OAuth Working Group published the first draft of OAuth 2.0. OAuth 2.0 is a completely new protocol and is not backward compatible with OAuth 1.0. Updated features include a new authorization code flow to accommodate mobile applications, simplified signatures, and short-lived tokens with long-lived authorizations.
The 4 OAuth Roles
Resource owner. The entity capable of approving access to a resource. This is most commonly a person or end user.
Client. An application requesting access to a resource hosted on the resource server. It can be any type of requestor, including a server, webpage, computer, smartphone, app, or IoT device.
Resource server. The server that hosts the resource the client is trying to access. It can respond to requests with a valid authorization token.
Authorization server. The server that accepts the resource owner’s approval and issues an access token to the client.
How OAuth 2.0 Works (The Authorization Code Grant)
The client directs the resource owner to the authorization server. The resource owner authenticates and approves access. The authorization server redirects back to the client with an authorization code. The client exchanges the authorization code for an access token. The client uses the access token to request resources from the resource server. The resource server validates the token and returns the requested data. The user never shares credentials with the client application.
OAuth Security Considerations
OAuth is only as secure as your implementation. Always use the authorization code grant with PKCE for native and mobile apps. Never use the implicit grant. Validate redirect URIs exactly to prevent open redirect attacks. Store client secrets securely, never in client-side code. Use short-lived access tokens and longer-lived refresh tokens with rotation. Require TLS for all OAuth endpoints.
OAuth vs SAML vs OpenID Connect
OAuth handles authorization (what you can do). SAML handles authentication (who you are). OpenID Connect sits on top of OAuth 2.0 to add authentication. For many applications, you need OpenID Connect for identity plus OAuth for API access. Use OAuth alone when you only need delegated access to APIs. Use OpenID Connect when you need user identity information.
OAuth is not simple. The specification is complex. But following best practices prevents common vulnerabilities. Validate redirects. Use PKCE. Keep tokens short-lived. Encrypt everything. OAuth is powerful when implemented correctly and dangerous when done poorly.
