Guides / Concepts explained

What Is OAuth? "Sign in with Google" and Delegated Access Explained

OAuth lets an app access another service for a user without their password. How it works, scopes, tokens, OpenID Connect and what to ask your AI builder.

Mythex Team · 2026-09-29 · 5 min read

OAuth is an open standard that lets a user give one app limited access to their account on another service, without handing over their password. When you click "Connect Google Calendar" and see a screen asking "Allow this app to see your events?", that's OAuth. The app gets a token for exactly what you approved, which you can revoke at any time. The same machinery, with an extra layer called OpenID Connect, powers "Sign in with Google" and similar buttons.

Why OAuth matters when you build with AI

OAuth shows up in two common situations when you build an app:

1. Social login. You want your users to "Sign in with Google" (or Apple, Microsoft, GitHub) instead of creating another password. See how to add login to your app.
2. Connecting to users' accounts on other services. Your app needs to read a user's calendar, post to their social account, pull files from their cloud drive or sync their accounting data.

In both cases your AI builder can write the code, but some steps only you can do: creating a developer app with the provider, getting a client ID and client secret, registering callback URLs and, for some permissions, passing the provider's review. Knowing how OAuth works makes those steps — and the errors they produce — much less mysterious. For the bigger picture of login, see what authentication is.

An everyday analogy

Think of a hotel key card. At check-in, the front desk confirms who you are, then gives you a card that opens your room and the gym — not the other rooms, not the staff areas — and stops working at checkout. The card doesn't contain your passport. If you lose it, the desk cancels it and issues a new one.

• The front desk is the authorization server (Google's sign-in page).
• Your ID check is you logging in to Google.
• The key card is the access token.
• "Room and gym only" are the scopes you approved.
• Checkout is the token expiring, or you revoking access.

The app you're using never sees your Google password, only the key card.

How OAuth works, step by step

The most common flow for web apps is the authorization code flow. Here's what happens when a user connects their Google Calendar to a scheduling app:

1. Click. The user clicks "Connect Google Calendar."
2. Redirect to the provider. The app sends the browser to Google with its client ID, the scopes it wants (read calendar events) and the redirect URI where Google should send the user back.
3. Log in and consent. The user signs in to Google (if not already) and sees a consent screen listing what the app is asking for. They click Allow.
4. Back with a code. Google redirects the browser to the app's redirect URI with a short-lived, one-time authorization code.
5. Exchange on the server. The app's server sends that code, plus its client secret, directly to Google and receives an access token (and often a refresh token).
6. Use the API. The server calls Google Calendar's API with the access token and gets the user's events.

The callback in step 4 looks something like this:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

And the token response in step 5 is JSON like:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

The important design point: the token exchange happens server-to-server, so the client secret and tokens never need to pass through the browser.

OAuth vs OpenID Connect vs your own login

Many apps combine them: email-and-password login, plus "Sign in with Google" via OIDC, plus separate OAuth connections to other services.

Key terms

Common misconceptions

• "OAuth is a login system." Plain OAuth grants access; OpenID Connect handles identity. Using a bare access token as proof of who someone is has caused real security bugs.
• "The app gets my password." It never does. That's the point.
• "Asking for more scopes is harmless." Users are warier of broad requests, and providers such as Google may require an app review for sensitive or restricted scopes. Ask only for what you need.
• "The client secret can go in the frontend." Anything in browser code is public. Keep it in server-side secrets.
• "It works in testing, so it'll work in production." Providers often limit unverified apps — for example, to listed test users — and the redirect URI for your live domain has to be registered separately.
• "Tokens last forever." Access tokens expire quickly, and users can revoke access. Your app has to handle both gracefully.

What to ask your AI builder

• "Add 'Sign in with Google' using OpenID Connect with a well-maintained auth library — don't hand-roll the OAuth flow."
• "Use the authorization code flow with PKCE and check the state parameter."
• "Read the client ID and client secret from environment variables on the server."
• "Request only the scopes we need: read-only calendar access."
• "Tell me every redirect URL I need to register in the provider's console, for the preview, the published URL and my custom domain."
• "Store refresh tokens encrypted in the database, and handle expired or revoked tokens by asking the user to reconnect."
• "Let users disconnect the integration from their settings page."

OAuth and Mythex

Mythex doesn't have built-in end-user login for the apps you build; its docs describe a bring-your-own approach — you choose an auth library or hosted provider, store its keys as project secrets, and the agent writes the code. The add authentication recipe has a starter prompt for this. You'll also meet OAuth in Mythex itself: you can sign up with Google, connecting GitHub for repo sync uses GitHub OAuth, and AI clients that connect to Mythex over MCP go through an OAuth consent page. For more, see what authentication is and what two-factor authentication is.