What Is OAuth?
OAuth is an open standard that lets you grant one app limited access to your data on another service without sharing your password. It is the technology behind 'Sign in with Google' and 'Connect to Facebook' buttons. Instead of handing over your login, you approve a specific permission — say, letting a design tool read your Google Drive files — and the service issues the app a temporary access token scoped to just that. You can revoke that access anytime, and your password is never exposed.
- What it is
- An open authorization standard for delegated access without sharing passwords
- Current version
- OAuth 2.0 is the widely used version, defined in RFC 6749 (IETF)
- Key idea
- Apps receive scoped, revocable access tokens instead of your credentials
- Common use
- Powers 'Sign in with Google/Apple/Facebook' and app-to-app connections
- Not the same as
- OAuth handles authorization; OpenID Connect adds login/identity on top (OpenID Foundation)
What OAuth actually does #
OAuth is a standard way to let one application use your data on another service without ever seeing your password. When a photo-printing site asks to access your Google Photos, OAuth is what makes that possible safely: you log in to Google directly, approve a specific request, and Google hands the printing site a temporary token that grants only the access you approved. The printing site never learns your Google password and can only do what you allowed — read your photos, perhaps, but not your email. This idea is called delegated authorization: you delegate a slice of your access to another app, on your terms, and you can withdraw it later. OAuth is now the backbone of app connections across the web, from social logins to integrations between business tools. Understanding it helps you judge which permissions to grant and which to refuse. If your business connects several software tools together, our /services/api-crm-integrations page explains how those authorized links are set up and kept secure.
The problem OAuth solves #
Before OAuth, letting one service use another meant handing over your actual username and password — a genuinely dangerous practice. If you gave a scheduling app your email login so it could send invitations, that app now had total control of your inbox, could change your password, and stored your credentials wherever it liked. If the app was breached, so was your account. OAuth was created to end this. Instead of sharing the password, you authenticate directly with the service you trust, then approve a narrow, specific permission for the third-party app. The app receives a token, not your password, and that token is limited to what you approved and can be revoked without changing your password or affecting anything else. This separation is the whole point: it lets useful integrations exist without any app holding the keys to your entire account. For any business wiring tools together, that principle prevents one weak link from compromising everything. Our /services/website-security page applies the same least-access thinking across your whole setup.
How the OAuth flow works #
The most common OAuth sequence, called the authorization code flow, moves through a few clear steps. First, you click 'Connect' or 'Sign in with Google' in an app. The app redirects your browser to the provider — Google, in this case — where you log in directly on Google's own page, so the app never sees your credentials. Google then shows a consent screen listing exactly what the app is requesting, such as reading your calendar. When you approve, Google sends your browser back to the app with a short-lived authorization code. The app exchanges that code, behind the scenes, for an access token, and uses that token on future requests to fetch the approved data. Often it also receives a refresh token to get new access tokens without asking you again. Each handoff keeps your password with the provider and gives the app only a scoped token. This dance happens in seconds, invisibly. Our /services/web-app-development team implements these flows correctly so your users' logins stay both smooth and safe.
Scopes, tokens and consent #
A scope names one specific permission an app requests, and the provider returns a token limited to those scopes. Here is a simplified authorization request and the token response it leads to.
# 1) App sends the user to the provider with requested scopes
GET https://accounts.google.com/o/oauth2/v2/auth
?client_id=APP_ID
&redirect_uri=https://yourapp.com/callback
&response_type=code
&scope=openid%20email%20drive.readonly
# 2) After consent, the app exchanges the code and receives:
{
"access_token": "ya29.a0Af...",
"token_type": "Bearer",
"expires_in": 3599,
"scope": "openid email drive.readonly",
"refresh_token": "1//0gA..."
}OAuth vs OpenID Connect vs SAML #
OAuth is often confused with related standards, but each has a distinct job. OAuth itself handles authorization — granting an app permission to do something with your data. It was not originally designed to prove who you are. That gap is filled by OpenID Connect, a thin identity layer built on top of OAuth 2.0 that adds a standardized way to verify a user's identity; it is what technically powers most 'Sign in with Google' logins. SAML is an older standard that solves similar single-sign-on problems, common in enterprise and workplace software, using XML rather than the lightweight tokens OAuth favors. In everyday terms: OAuth says what an app may access, OpenID Connect says who you are, and SAML is the enterprise veteran doing both in legacy systems. For most modern small-business tools, OAuth 2.0 with OpenID Connect is the pairing you will meet. Our /services/api-crm-integrations team knows which standard each vendor uses and connects them correctly so logins and data flows behave as expected.
Where you already use OAuth #
You almost certainly use OAuth many times a day without noticing. Every 'Sign in with Google,' 'Continue with Apple,' or 'Log in with Facebook' button relies on it. When you connect your email marketing tool to your online store, authorize an accounting app to read your bank feed, or let a social scheduler post to your business page, OAuth is granting that access behind the scenes. It also underpins mobile apps that link to cloud services and the integrations inside platforms like Shopify and WordPress. The reason it is everywhere is simple: it makes connecting services safe enough to be routine. For a small business, this means the tools you already rely on are quietly exchanging scoped tokens rather than passwords, which is exactly what you want. When you review which apps have access to your accounts, you are looking at your OAuth grants. Our /services/ai-chatbots and /services/email-marketing integrations use these same authorized connections so your systems share data without anyone copying passwords around.
Security benefits and risks #
OAuth's core benefit is containment: because apps hold scoped, revocable tokens instead of your password, a breach of one connected app cannot hand over your whole account, and you can cut off any app instantly from your account settings. Tokens expire, limiting how long a stolen one is useful, and you can see exactly what each app was permitted to do. But OAuth is not magic, and it has its own risks. Users often approve broad permissions without reading the consent screen, granting more access than an app truly needs. Phishing attacks can mimic a legitimate consent page to trick you into authorizing a malicious app. And poorly built integrations can mishandle or leak tokens. The defenses are practical: read consent screens, grant the narrowest scope that works, and periodically review and revoke apps you no longer use. Treat an OAuth grant with the same care as a password. Our /services/website-security page helps businesses audit which apps hold access and tighten permissions that drifted too broad over time.
OAuth for small business websites #
If your website offers accounts, OAuth-based social login can lower the barrier to signing up: visitors click 'Sign in with Google' instead of inventing yet another password, which reduces friction and abandoned registrations. It also shifts the burden of storing passwords onto trusted providers, so your site holds fewer sensitive credentials to protect. On the integration side, OAuth is how your site safely connects to the CRMs, payment tools, and marketing platforms that run your operations, exchanging tokens rather than passwords. The tradeoff to weigh is dependence: if you rely solely on social login and a provider changes its rules, some users could be affected, so offering a normal email login alongside is wise. Implemented well, OAuth improves both convenience and security at once, which is a rare combination. Our /services/web-app-development team can add social login and authorized integrations to your site, and /services/conversion-optimization can tell you whether reducing sign-up friction actually lifts your registrations for your specific audience.
Common OAuth pitfalls #
OAuth is powerful but easy to implement or use carelessly, and the mistakes tend to repeat. On the building side, developers sometimes request far more scopes than a feature needs, store tokens insecurely, or skip validating the state parameter that protects against a class of attacks — each a real weakness. On the using side, businesses often accumulate dozens of authorized apps over the years and never revisit them, leaving old, forgotten grants as standing risks. Another common trap is confusing authorization with authentication: OAuth alone proves an app may access data, not necessarily who the user is, which is why OpenID Connect exists for login. Finally, users click through consent screens reflexively, approving access they would refuse if they read it. Good practice is to request minimal scopes, review granted apps regularly, revoke what you no longer use, and pair OAuth with proper identity handling. Our /services/website-security team audits these grants and configurations so your connected apps follow least-privilege rather than quietly widening over time.
FAQ
Is OAuth a login system?
Not by itself. OAuth handles authorization — granting an app permission to access data. Logging in, which proves who you are, is added by OpenID Connect, a layer built on top of OAuth 2.0. Most 'Sign in with Google' buttons technically use OpenID Connect, so people loosely call the whole thing OAuth even though the two do different jobs.
Does OAuth share my password?
No, and that is the entire point. With OAuth you log in directly with the trusted provider, which then gives the third-party app a limited token instead of your credentials. The app never sees or stores your password, so even if that app is later breached, your password and full account remain protected.
Can I revoke an app's OAuth access?
Yes, at any time. Providers like Google, Microsoft, and Facebook have a security or connected-apps page listing every app you have authorized, with a button to remove each one. Revoking invalidates that app's tokens immediately, cutting off its access without changing your password or affecting other connected apps.
What is an OAuth scope?
A scope is a named permission an app requests, such as reading your calendar or seeing your email address. When you approve, the provider issues a token limited to those scopes, so the app can only do what you allowed. Granting the narrowest scopes that still make a feature work is the safest habit.
Is OAuth safe?
It is far safer than sharing passwords, because apps receive scoped, expiring, revocable tokens. The remaining risks come from users approving overly broad permissions, phishing pages that mimic real consent screens, and developers mishandling tokens. Reading consent screens, granting minimal access, and reviewing connected apps periodically keeps those risks small.
What is the difference between OAuth and an API key?
An API key is a static secret identifying an application, typically for server-to-server calls. OAuth issues temporary, scoped tokens after a user grants permission, so it is used when an app acts on a specific person's behalf. OAuth tokens expire and can be revoked individually, which limits damage more than a long-lived key.
How Local Web Advisor checks this for you
Is your own website getting security & compliance right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for security & compliance and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?