What Is OAuth 2.0?
OAuth 2.0 is an authorisation framework that allows a user to grant a third-party application limited access to their account on another service, without revealing their password. For example, when you click 'Sign in with Google', Google authenticates you and then issues an access token to the application. The app uses that token to access only the data the user approved, such as their profile or calendar, and can never see the password itself.
OAuth 2.0 lets users grant an app access to their data on another service without sharing their password.
Why OAuth 2.0 Exists
Before OAuth, applications that needed access to your data on another service had a simple but dangerous solution: they asked for your username and password and logged in on your behalf. This meant the application stored your credentials, could access everything in your account (not just what it needed), and if the application was compromised, so was your account on the other service.
OAuth 2.0, published as an IETF standard in 2012, solved this problem by introducing a delegation model. Instead of sharing your password, you grant the application a token that represents a limited, revocable permission. You can revoke that permission at any time without changing your password.
Today OAuth 2.0 underpins almost every modern API integration: social login buttons, calendar syncing, file access, payment authorisation, and more.
The Authorization Code Flow Explained
There are several OAuth 2.0 flows for different scenarios, but the Authorization Code Flow is the most common and the most secure for applications that run on a server.
The sequence works like this:
- You click “Connect with Google” in an application.
- The application redirects your browser to Google’s authorisation server with its client ID, the requested scopes, and a redirect URL.
- Google shows a consent screen listing what the application wants access to (for example, “Read your Google Calendar”).
- You click Allow. Google redirects your browser back to the application’s redirect URL with a short-lived authorisation code.
- The application’s server exchanges that code for an access token and a refresh token by making a server-to-server request to Google, authenticating with its client secret.
- The server stores the tokens securely and uses the access token to call Google’s APIs on your behalf.
The key insight is that your password never leaves Google, and the access token is obtained server-side, so it is never exposed in a browser URL or accessible to JavaScript on the page.
Access Tokens, Refresh Tokens, and Scope
Access tokens are intentionally short-lived, typically 15 to 60 minutes. This limits the damage if a token is intercepted: after an hour, it is useless. When the access token expires, the application uses the refresh token (which lives for days or months) to obtain a new one silently.
Scope defines exactly what the token can do. An application that only needs to read your email address requests email scope. One that needs to create calendar events requests calendar.events.write. The consent screen shows these scopes in plain language before you approve. If you later decide the application should not have that access, you revoke the permission in your account settings, and the token immediately stops working.
This combination of short-lived tokens and explicit scope is why OAuth 2.0 is considered secure: every permission is visible, limited, and revocable.
Concrete Examples You Encounter Every Day
The most visible OAuth 2.0 flow is the “Sign in with Google” or “Sign in with Microsoft” button on third-party websites. The website never receives or stores your Google password. It receives an ID token (via OpenID Connect, which builds on OAuth 2.0) that confirms who you are.
A less visible example: when you connect a marketing tool like HubSpot to your Gmail to send emails on your behalf, that connection uses OAuth 2.0. HubSpot receives an access token with the scope to send email via the Gmail API. It does not know your Gmail password and cannot access your contacts unless you also granted that scope.
For authentication in web applications more broadly, OAuth 2.0 is the standard building block. If you are building integrations that connect to third-party services, REST APIs are almost always the underlying transport layer that OAuth 2.0 tokens are used to access. Most identity providers, including Auth0, Supabase Auth, and Microsoft Entra ID, implement OAuth 2.0 and OpenID Connect under the hood, so you inherit its security model even when you are using a higher-level SDK.
When You Need to Think About OAuth 2.0
As a developer or product owner, you encounter OAuth 2.0 in two scenarios. The first is when you build a feature that connects to a third-party service (reading from a Google Sheet, posting to LinkedIn, reading Outlook calendar). You will need to register an application with that service, obtain a client ID and secret, and implement the flow.
The second scenario is when you allow users to log into your application using an identity provider such as Google, Microsoft, or Apple. In this case you are consuming OAuth 2.0, and a library or identity platform handles the details. Either way, understanding the token model and scope concept prevents the most common security mistakes.
Our tip: Never store access tokens in browser localStorage. A cross-site scripting vulnerability in any script on your page can read localStorage. Store access tokens in memory for browser-based apps, and use HttpOnly cookies or server-side sessions for anything that needs to persist across page loads.
Frequently asked questions
What is the difference between OAuth 2.0 and OpenID Connect?
OAuth 2.0 is an authorisation protocol: it answers the question 'can this app access this resource on your behalf?' It issues access tokens but does not define how identity is conveyed. OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0 that adds the concept of the ID token, a signed JSON Web Token containing the user's identity (name, email, user ID). In practice, when you use 'Sign in with Google' or 'Sign in with Microsoft', the underlying protocol is OpenID Connect, which uses OAuth 2.0 flows to also return an ID token alongside the access token.
What is an access token and a refresh token?
An access token is a short-lived credential (typically valid for 15 minutes to 1 hour) that an application sends with every API request to prove it has been authorised. Because access tokens expire quickly, a refresh token is issued alongside them. A refresh token is long-lived (days to months) and is stored securely by the application. When the access token expires, the application exchanges the refresh token for a new access token without asking the user to log in again. Refresh tokens should never be sent to the client browser; they belong on the server side.
What is OAuth 2.0 scope?
Scope is the mechanism that limits what an application can do with the access token it receives. When an application starts the OAuth 2.0 flow, it declares which permissions it needs, for example `email`, `calendar.read`, or `files.write`. The authorisation server shows the user a consent screen listing those permissions. If the user approves, the issued token is restricted to exactly those scopes and cannot be used to access anything beyond them. This principle of least privilege means that even if a token is intercepted, the damage is limited to what that specific scope allowed.