Quick answer: OAuth is an open standard that lets one application access your data in another application without you handing over your password. When you click “Connect to Google” in an app and see a screen asking whether to allow access to your calendar, that is OAuth. You log in directly with Google, Google asks you to approve specific permissions, and the app receives a token that works only for those permissions. You can revoke that token at any time without changing your password. Most modern integrations between business tools use OAuth 2.0.
The problem OAuth solves
Before OAuth became common, connecting two services often meant typing your username and password for one service into the other. A reporting tool might ask for your email password so it could read your inbox, or an accounting add-on might store your bank login.
That approach had serious problems:
- The third-party app had full access to your account, not just what it needed
- Your password was stored in yet another place that could be breached
- Changing your password broke every connected app
- There was no easy way to see or remove which apps had access
OAuth replaced this with a system of limited, revocable permissions.
A simple analogy
Think of a hotel key card. At check-in you prove who you are at the front desk. The hotel gives you a card that opens your room and maybe the gym, but not other rooms or the office. The card stops working on your checkout date, and the hotel can cancel it at any time.
OAuth tokens work the same way. You prove who you are to the service that holds your data. That service gives the app a token that opens only certain doors, for a limited time, and you can cancel it.
The main parts of OAuth
You will hear these terms when developers talk about OAuth:
- Resource owner: you, or your user, who owns the data.
- Client: the application that wants access, such as your website or a reporting tool.
- Authorization server: the service that checks who you are and issues tokens, such as Google, Microsoft or Salesforce.
- Resource server: the API that holds the data and accepts tokens.
- Access token: a credential the client sends with each request to the API. It usually expires after a short time.
- Refresh token: a longer-lived credential used to get new access tokens without asking the user to log in again.
- Scopes: the specific permissions requested, such as “read calendar” or “send email”.
How it works, step by step
The most common pattern is called the authorization code flow. Here is what happens when a user connects your app to their Google account:
- The user clicks “Connect Google account” in your app.
- Your app sends the user to Google’s login page with a list of the scopes it wants.
- The user logs in on Google’s own page. Your app never sees the password.
- Google shows a consent screen listing the permissions. The user approves.
- Google sends the user back to your app with a short-lived code.
- Your app’s server swaps that code for an access token, and often a refresh token, in a private request to Google.
- Your app uses the access token to call Google’s API for the data it is allowed to see.
If the user later removes access from their Google account settings, the token stops working.
OAuth versions
- OAuth 1.0a was the first widely used version. It required requests to be cryptographically signed and was hard to implement. A few older APIs still use it.
- OAuth 2.0, published in 2012, is the version almost every modern API uses. It is simpler for developers and relies on HTTPS to protect tokens in transit.
The two versions are not compatible. If an integration mentions OAuth, it almost always means OAuth 2.0 today.
OAuth is not a login system on its own
OAuth was designed for granting access to data, not for proving who someone is. OpenID Connect is a layer built on top of OAuth 2.0 that adds identity. It returns an ID token with basic profile details such as name and email.
When you add “Sign in with Google” or “Sign in with Microsoft” to a website, you are usually using OpenID Connect. It saves users from creating another password and can reduce sign-up friction, though you depend on the other provider being available.
Different flows for different situations
OAuth 2.0 defines several ways to get a token, called flows or grant types:
- Authorization code flow: for web applications with a server. The standard choice.
- Authorization code with PKCE: an extension that adds protection for mobile apps and single page applications that cannot keep a secret safely. Current security guidance from the people who maintain the standard recommends it for these apps.
- Client credentials: for server-to-server connections where no user is involved, such as a nightly job syncing data between two of your own systems.
- Implicit flow: an older approach for browser apps that returned tokens directly in the URL. It is now discouraged because tokens can leak.
- Password grant: where the user types their password into the client app. Discouraged except in narrow cases, since it defeats much of the point of OAuth.
If your developer proposes the implicit or password flows for a new project, ask why.
Where you will meet OAuth in business projects
- Connecting a website or app to Google Calendar, Gmail, Google Drive or Google Analytics
- Integrating with Microsoft Office 365 or Azure Active Directory
- CRM integrations with Salesforce, HubSpot or Zoho. Our article on Salesforce integration covers one common example.
- Accounting connections with Xero or QuickBooks Online
- Social login and posting to Facebook, Twitter or LinkedIn
- Payment platforms such as Stripe Connect, where businesses link their own accounts
- Your own API, if you let partners or customers build on it
For background on how APIs fit together, see our guide What is an API?.
Security points to get right
OAuth is secure when implemented well, and risky when corners are cut. Things a good developer will handle:
- HTTPS everywhere. OAuth 2.0 depends on encrypted connections.
- Exact redirect URLs. The authorization server should only send codes back to pre-registered addresses. Loose matching has caused real breaches.
- State parameter. A random value that protects against cross-site request forgery during the login step.
- Minimal scopes. Ask only for the permissions the feature needs. Users are more likely to approve, and less data is exposed if something goes wrong.
- Safe token storage. Access and refresh tokens are as sensitive as passwords. Store them encrypted on the server, not in browser storage where scripts can read them.
- Short-lived access tokens. Use refresh tokens to get new ones, and revoke tokens when users disconnect.
- Handle expired and revoked tokens gracefully, with a clear message asking the user to reconnect.
Our guides to API security and the OWASP Top 10 cover wider security practice.
Building your own OAuth server
If you are offering your own API, you may need to issue tokens to other apps. Writing an authorization server from scratch is rarely a good idea. Use a well-maintained library or an identity service such as Auth0, Okta, Amazon Cognito or Azure Active Directory B2C. These handle the difficult parts and are tested by many users.
Our article on custom API development covers the wider planning of an API.
Questions to ask your developer
- Which OAuth flow are you using, and why?
- What scopes will we request, and are they the minimum needed?
- Where and how are tokens stored?
- What happens when a token expires or a user revokes access?
- Are we using a tested library or identity provider, or custom code?
- Will the consent screen show our business name and logo clearly?
- Does the provider need to review our app before it goes live? Google, for example, requires verification for apps requesting sensitive scopes.
FAQ
Is OAuth the same as two-factor authentication?
No. Two-factor authentication strengthens a login with a second step. OAuth controls what a connected app can access. They work well together.
Does OAuth mean the app can see my password?
No. You log in on the provider’s own page, and the app only receives a token.
How do I remove an app’s access?
Most providers have a page listing connected apps, often called security settings or third-party access, where you can revoke access.
Is OAuth free to use?
The standard is open and free. Some identity services charge based on the number of users.
Safer connections between your tools
OAuth lets your website and business systems share data without passing passwords around, and gives users control over what each app can do. When it is set up properly, integrations are both safer and easier to manage. If you are planning an integration or custom application that needs secure access to other services, see our Custom development service.
