What is OAuth?

What it is

Before OAuth, an app that wanted to read your calendar or contacts often asked for your password, which gave it full access and no way to revoke it. OAuth 2.0 replaced that with tokens. The person approves a specific scope of access on the provider's page, the provider issues an access token to the app, and the app uses it until it expires or the person revokes it. OAuth itself only grants access. OpenID Connect, a layer on top, adds an ID token that tells the app who signed in, with a stable user identifier and, if requested, an email address and name.

How the flow works

The common flow for websites is the authorisation code flow. The site redirects the person to the provider with its client id, the scopes it wants, a redirect address and a random state value. The person signs in and approves. The provider sends them back to the redirect address with a short lived code. The site's server exchanges that code, with its client secret, for tokens. Apps that cannot keep a secret, such as phone apps and single page apps, add PKCE, defined in RFC 7636, so a stolen code is useless. Redirect addresses must be registered with the provider in advance, which is why sign in can work on one address and fail on another.

When it matters

For a small business site, OAuth matters as social sign in. Many visitors prefer one tap with Google to inventing another password, and the site receives a verified email address. It also matters when connecting the business's own tools, such as letting a site post to a calendar, where the business owner approves access once. It is not needed for a site with no accounts, and it does not replace a password option for visitors who do not want to link their Google account.

Common mistakes

Treating an access token as proof of identity instead of validating the ID token. Skipping the state parameter, which opens the door to cross site request forgery. Putting the client secret in browser or app code. Registering broad redirect patterns that an attacker could abuse. Asking for more scopes than needed, which scares people off at the consent screen. Forgetting that Google requires an app to be verified before some scopes are shown to the public. And linking accounts by email address alone without checking the provider verified the email.

Where it shows up in OneCraft

Visitor login on OneCraft sites is email and password through Supabase Auth with a password reset, plus Google sign in through OneCraft's broker, which works on the published site and on the installed app. Sign in belongs to the site's own database, set up by the agent when a capability needs data, with row level security on every table. The agent checks each new table as an anonymous visitor and as a signed in person before a generation step can finish.

Questions people ask