OAuth is an open standard for granting permission. It lets you tell a service like Google, "allow this scheduling app to see my calendar", without typing your Google password into the scheduling app. The app receives a limited token instead, and you can revoke it at any time.
The authorisation code flow, step by step
OAuth 2.0, published as RFC 6749 in 2012, is the version in use. The most common flow goes like this:
- The app sends you to the provider's consent screen, listing the scopes it wants, such as "read calendar events".
- You sign in at the provider (your password never touches the app) and click Allow.
- The provider redirects back to the app with a short-lived authorisation code.
- The app's server swaps that code, plus its own client secret, for an access token and often a refresh token.
- The app calls the provider's API with the access token. When it expires, the refresh token gets a new one.
Public apps that cannot keep a secret, like single-page apps and mobile apps, add PKCE, a one-time proof that stops an intercepted code from being reused. The upcoming OAuth 2.1 draft makes PKCE standard for everyone.
A real example: connecting a booking tool to Google Calendar
A hair salon signs up for a booking app and clicks "Connect Google Calendar". Google shows which permissions are requested. After approval, new appointments appear in the stylist's calendar. Later, the salon can open its Google account's third-party access page and remove the app, which kills the token without changing any password.
OAuth versus logging in
OAuth is about permission to act on your data, not about proving who you are. "Sign in with Google" adds OpenID Connect on top of OAuth to deliver an identity token, usually a JWT. That combination is what most consumer single sign-on uses.
When a small business runs into OAuth
Constantly, as a user: connecting Mailchimp to Shopify, a form tool to Google Sheets or Zapier to your CRM are all OAuth grants. You only build it if your own app needs to read customers' data from another service, and then you should use the provider's SDK rather than hand-coding the flow.
OAuth mistakes
- Clicking Allow on broad scopes like "read, send and delete all email" for a tool that only needs your contacts.
- Never reviewing connected apps, leaving tokens active for tools you stopped using years ago.
- Shipping the client secret inside browser or mobile code where anyone can read it.
- Loose redirect URLs registered with wildcards, which let attackers capture codes.
Related terms
- Single sign-on: often built on OAuth plus OpenID Connect.
- JWT: a common format for OAuth and ID tokens.
- API: what an OAuth access token unlocks.
- Webhook: often registered after an OAuth connection is made.