# What is OAuth? Delegated sign-in explained Source: https://www.plutonapps.com/resources/what-is-oauth Published 2026-09-30, updated 2026-10-24, sources checked 2026-10-24. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib). **OAuth:** OAuth 2.0 is an open standard that lets an app get limited access to a user's account on another service, such as their Gmail or calendar, without ever seeing their password. The user approves specific permissions, called scopes, and the app receives a token it can use until it expires or is revoked. Also known as: OAuth 2.0. The protocol behind every "Continue with Google" button and every app that asks for access to your calendar. ## Where does OAuth show up in an app, and where is the risk? OAuth shows up in two ways. For sign-in, "Continue with Google" uses OpenID Connect, an identity layer on top of OAuth 2.0; providers such as Clerk run that flow for you. For integrations, your app asks a user for access to their account elsewhere, and then holds tokens that can act as them. The second is where production risk lives. Those tokens are credentials: they belong encrypted on the server, never in the browser. Ask for the fewest scopes that do the job, because users see the list and reviewers check it. ## How does the OAuth authorization code flow work, step by step? In the authorization code flow, your app sends the user to the provider, the user approves the scopes, and the provider sends back a short-lived code. Your app swaps that code for an access token, and often a refresh token. RFC 9700, the current security best practice, says to use this flow and not the older implicit grant. 1. **Redirect** Your app sends the user to the provider with the scopes it wants and a redirect address. 2. **Consent** The user signs in at the provider, never on your site, and approves the listed scopes. 3. **Code** The provider redirects back to your exact registered address with a one-time code. 4. **Token** Your server exchanges the code for tokens and stores them as secrets. ## What OAuth mistakes should you check for before launch? Most OAuth problems come from skipping the protections RFC 9700 asks for. The flow still works in a demo, so nothing looks wrong until a token leaks or a redirect is abused. These are the checks worth making before real users connect their accounts. - Browser and mobile apps use PKCE. RFC 9700 says public clients must, with the S256 method. - Redirect addresses are compared by exact string match, not by pattern. - Access tokens carry the least privilege needed. - Refresh tokens for public clients are sender-constrained or rotated. - Provider tokens are stored on the server, never in client code or local storage. If you use Supabase Auth for Google or GitHub sign-in, its docs note that Supabase does not refresh provider tokens or store them in your database. If your app calls the provider's API later, it has to keep and refresh those tokens itself, which is a [secrets management](https://www.plutonapps.com/resources/what-is-secrets-management) job. If an AI builder wired this up for you, the [vibe-coding rescue](https://www.plutonapps.com/services/vibe-coding-rescue) page explains how we review it. > **What we see in practice** [Bell](https://www.plutonapps.com/work/bell), an AI email assistant, connects to Gmail with access limited to reading and sending. It never asks for more than the product needs. ## Frequently asked questions ### What is the difference between OAuth and OpenID Connect? OAuth grants an app access to resources, such as a calendar or inbox. OpenID Connect is a thin identity layer on top of OAuth 2.0 that also tells the app who the user is, which is what sign-in needs. Continue with Google buttons use OpenID Connect. ### Can OAuth be used for single sign-on? Yes, through OpenID Connect, which adds sign-in to OAuth 2.0. SAML is the other common standard for enterprise single sign-on. Providers such as Clerk run either flow for you, so your app never has to implement the protocol itself. Your app only checks the result and opens a session. ### What is PKCE and does my app need it? PKCE, Proof Key for Code Exchange, ties the code returned by the provider to the app that asked for it, so a stolen code is useless. RFC 9700 says public clients such as browser and mobile apps must use it, and recommends it for server apps too. ### Is the OAuth implicit grant still safe to use? No. RFC 9700, the OAuth 2.0 security best practice, says clients should not use the implicit grant, which returns an access token straight in the redirect. Use the authorization code flow with PKCE instead. Most sign-in providers and SDKs already do this by default. ## Read next - [The Bell case study: Gmail access limited to read and send](https://www.plutonapps.com/work/bell) ## Sources - [RFC 6749: The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749) - [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) - [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700) - [Supabase docs: Social login](https://supabase.com/docs/guides/auth/social-login)