What is OAuth? Delegated sign-in explained
The protocol behind every "Continue with Google" button and every app that asks for access to your calendar.
In short
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 called: OAuth 2.0
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.
- 01RedirectYour app sends the user to the provider with the scopes it wants and a redirect address.
- 02ConsentThe user signs in at the provider, never on your site, and approves the listed scopes.
- 03CodeThe provider redirects back to your exact registered address with a one-time code.
- 04TokenYour 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 job. If an AI builder wired this up for you, the vibe-coding rescue page explains how we review it.
Common 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.
Go deeper
Lovable authentication and secure user rolesHow to add sign-in and user roles to a Lovable app safely: where roles must live, how to protect admin areas, Google sign-in, MFA, and how to test it all.
Related terms
Read next
Sources
- RFC 6749: The OAuth 2.0 Authorization Framework
- OpenID Connect Core 1.0
- RFC 9700: Best Current Practice for OAuth 2.0 Security
- Supabase docs: Social login
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
