What Is OAuth? (Plain English)

OAuth is the reason you can click "Sign in with Google" instead of creating yet another password. It's an authorization protocol that lets apps access your data without ever seeing your login credentials.

Here's what that means in practice: When a scheduling tool asks to "access your Google Calendar," OAuth handles the handshake. Google confirms your identity, you approve specific permissions, and the scheduling tool gets a temporary access token. No passwords change hands. The tool never learns your Google password.

This matters because most professional software you use daily runs on OAuth. Your practice management system connecting to QuickBooks. Your CRM

syncing with Outlook. Your time tracking tool pulling from Asana. All OAuth.

Every OAuth flow involves three parties:

Resource Owner: You. The person who owns the data (your calendar, your contacts, your files).

Client Application: The tool requesting access (the scheduling app, the CRM

, the budgeting software).

Authorization Server: The service that hosts your data and verifies your identity (Google, Microsoft, your bank).

The client never talks directly to your data. It asks the authorization server for permission. The authorization server asks you. You approve or deny. The authorization server gives the client a token if you approve. The client uses that token to access only what you authorized.

You're setting up a new project management tool. It needs access to your Google Drive to attach files. Here's the exact sequence:

Step 1: You click "Connect Google Drive" in the project tool.

Step 2: The project tool redirects you to Google's authorization page. The URL includes parameters specifying what the tool wants access to (read files, write files, delete files).

Step 3: Google shows you a consent screen listing exactly what permissions the tool is requesting. You see "View and manage files in your Google Drive" or "View files only."

Step 4: You click "Allow." Google generates an authorization code and sends you back to the project tool with that code in the URL.

Step 5: The project tool exchanges that authorization code for an access token by making a server-to-server call to Google. This happens behind the scenes.

Step 6: The project tool stores the access token (usually encrypted in its database). When it needs to read or write a file, it includes this token in the API request header.

Step 7: Google validates the token on every request. If the token is valid and hasn't expired, Google processes the request. If you've revoked access or the token expired, Google rejects it.

The project tool never sees your Google password. It only has a token that works for specific actions you approved.

Different application types use different OAuth flows. Knowing which flow an app uses tells you how secure the integration is.

Authorization Code Flow (Most Secure)

Used by: Web applications with server backends (most SaaS tools).

How it works: The app gets an authorization code first, then exchanges it for an access token on the server side. The access token never appears in your browser.

Security level: High. The app's client secret stays on the server. Even if someone intercepts the authorization code, they can't use it without the client secret.

Example: Your firm's document management system connecting to SharePoint.

Authorization Code Flow with PKCE (Mobile Apps)

Used by: Mobile apps and single-page web apps that can't securely store secrets.

How it works: The app generates a random "code verifier" and sends a hashed version (the "code challenge") with the authorization request. When exchanging the code for a token, it proves it has the original verifier.

Security level: High. PKCE prevents authorization code interception attacks even without a client secret.

Example: A mobile time tracking app connecting to your calendar.

Implicit Flow (Deprecated, But Still Common)

Used by: Older single-page apps.

How it works: The authorization server returns the access token directly in the URL fragment after authorization. No code exchange step.

Security level: Low. The token appears in the browser URL and can leak through browser history or referrer headers.

Status: OAuth 2.1 removes this flow entirely. If a vendor still uses it, that's a red flag.

Example: Legacy browser extensions (most have migrated to PKCE).

Client Credentials Flow (Machine-to-Machine)

Used by: Backend services, automated scripts, server-to-server integrations.

How it works: No user involved. The application authenticates with its client ID and secret, gets a token, accesses resources it owns.

Security level: High for the intended use case, but the token has full access to whatever the service account owns.

Example: Your billing system automatically pulling invoice data from your practice management software every night.

When you see that consent screen, you're approving "scopes." Scopes define exactly what the app can do.

Google Calendar scopes:

• calendar.readonly: Read your calendar events
• calendar.events: Read and write events
• calendar: Full access to all calendars

Microsoft Graph scopes:

• Mail.Read: Read your email
• Mail.ReadWrite: Read and modify email
• Mail.Send: Send email as you

The app requests specific scopes. You approve or deny the entire request. You can't approve some scopes and deny others in the same flow.

Critical point: An app requesting calendar (full access) when it only needs to read events is over-permissioning. That's either lazy development or a security concern.

OAuth uses two types of tokens:

Access Token: Short-lived (typically 1 hour). The app includes this in every API

request. When it expires, the API

API

Click to read the full definition in our AI & Automation Glossary.

rejects requests.

Refresh Token: Long-lived (days to months). The app uses this to get a new access token when the old one expires. The user doesn't see this happen.

This two-token system limits damage if an access token leaks. It's only valid for an hour. The refresh token stays on the server and is harder to steal.

Some providers (like Google) issue refresh tokens that don't expire unless you revoke access. Others (like Microsoft) rotate refresh tokens, issuing a new one each time you use it.

Email integrations: Your CRM

connecting to Outlook to log emails. OAuth scope: Mail.Read, Mail.Send, Contacts.ReadWrite.

Calendar scheduling: Calendly accessing your Google Calendar to check availability. OAuth scope: calendar.events.readonly, calendar.freebusy.

Document automation: Contract software pulling templates from SharePoint. OAuth scope: Files.Read.All, Sites.Read.All.

Accounting sync: Your practice management system pushing time entries to QuickBooks. OAuth scope: com.intuit.quickbooks.accounting.

SSO (Single Sign-On): Logging into your firm's intranet with your Microsoft 365 account. OAuth combined with OpenID Connect for identity.

Most services let you review and revoke OAuth grants:

Google: myaccount.google.com/permissions - Shows every app with access, what scopes they have, when you granted access.

Microsoft: account.microsoft.com/privacy/app-permissions - Lists all apps, lets you revoke individually.

GitHub: github.com/settings/applications - Separates OAuth apps from personal access tokens.

Salesforce: Setup → Security → OAuth and OpenID Connect Apps - Shows all connected apps and their scopes.

Review these quarterly. Revoke access for:

• Apps you no longer use
• Apps requesting scopes they don't need
• Apps you don't recognize (possible account compromise)

The app requests offline access but doesn't need it: Offline access means the app gets a refresh token and can access your data even when you're not using it. A one-time data export tool doesn't need this.

The consent screen shows a different company name than expected: You're connecting to "Project Tool Pro" but the consent screen says "Random Developer LLC." The developer might have sold the app or it's a phishing attempt.

The app requests admin consent for your entire organization: In Microsoft 365, some apps request tenant-wide permissions. Unless you're the IT admin intentionally setting up an org-wide integration, deny this.

The redirect URL looks suspicious: After you approve access, check where you land. It should be the app's domain, not a random subdomain or different domain entirely.

Passwords: The app stores your username and password, logs in as you. If the app gets breached, attackers have your credentials for the original service. Never do this.

API

Keys: You generate a key in the service, paste it into the app. The key usually has full account access and doesn't expire. Better than passwords, but still risky if the app stores it insecurely.

OAuth: The app never sees your password. You can grant limited permissions. You can revoke access anytime. Tokens expire. This is the current standard.

If a modern SaaS tool asks for your password to another service instead of using OAuth, find a different tool.

You revoke an app's OAuth access in Google. Here's what happens:

Immediate: Google invalidates all access tokens and refresh tokens for that app. The next time the app tries to use them, Google returns an error.

The app's response: Well-designed apps detect the revocation and prompt you to reconnect. Poorly designed apps show cryptic error messages or stop working silently.

Your data: Revoking access doesn't delete data the app already downloaded. If the scheduling tool cached your calendar events, those remain in its database. Check the app's data retention policy.

Reconnecting: You can re-authorize the same app later. It goes through the full OAuth flow again and gets new tokens.

OAuth is the authorization backbone of modern software integrations. It keeps your passwords secure while letting apps work together.

When you see a consent screen, read what you're approving. When you stop using an app, revoke its access. When evaluating new tools, check if they use OAuth instead of asking for passwords.

The five minutes you spend reviewing OAuth permissions prevents the five weeks you'd spend recovering from a compromised account.