# OAuth Explained: A Simple, Secure Guide to Google Sign-In URL: https://whattheweb.co.in/oauth-explained-a-simple-secure-guide-to-google-sign-in/ Published: 2026-11-11 Author: Vinita Mathreja Topics: System Design, Vibe Coding Updated: 2026-11-12 On this page 1. [What is OAuth?](#what-is-oauth) 2. [The hotel key card analogy, in simple words](#the-hotel-key-card-analogy-in-simple-words) 3. [How does OAuth work, step by step?](#how-does-oauth-work-step-by-step) 4. [Which four terms should you know?](#which-four-terms-should-you-know) 5. [Is OAuth for login or permission?](#is-oauth-for-login-or-permission) 6. [How do you add Google sign in to your own app?](#how-do-you-add-google-sign-in-to-your-own-app) 7. [Which five mistakes break sign in most often?](#which-five-mistakes-break-sign-in-most-often) 8. [OAuth FAQs](#oauth-faqs) ## What is OAuth? OAuth is a standard way to let one app access your stuff on another service without ever giving it your password. For example, the “Sign in with Google” button and “Connect your Google Calendar” are both OAuth in action. ![Hotel key card illustration showing how OAuth gives an app limited access without sharing your password](https://whattheweb.co.in/wp-content/uploads/2026/11/oauth-hotel-key-card-1200x630-1.webp) Here is the idea in four quick points: - **What it does:** it gives an app a limited, temporary pass instead of your password. - **Who decides:** the user. So they see exactly what the app wants and click Allow or Deny. - **Who holds the password:** only the service that owns it, like Google. As a result, the app never sees it. - **Why it matters:** if the app gets hacked, your password was never inside it. ## The hotel key card analogy, in simple words Think of a hotel key card. You do not hand a cleaner your master key. Instead, the front desk gives them a card that only opens your room, and only for today. OAuth works the same way: - **The master key** is your password. - **The front desk** is the service that holds your account, like Google. - **The key card** is the access the app receives. It is limited and temporary. - **The cleaner** is the app asking for access. The cleaner can do the job. However, they cannot wander into the rest of the building. Finally, when the day ends, the card stops working. ## How does OAuth work, step by step? There are four moves. The user only sees one screen. However, the rest happens behind the scenes. 1. **Your app sends the user to Google.** The user clicks “Sign in with Google” or “Connect your Google Calendar” and lands on a Google page. 2. **Google asks for permission.** The user sees a screen like, “This app wants to see your email and calendar. Allow?” 3. **The user approves.** Then Google sends them back to your app with a one time code. 4. **Your server swaps the code for an access token.** This happens behind the scenes. The token is the actual pass. 5. **Your app uses the token.** As a result, it can reach only what the user approved, nothing more. The key detail is step 4. In fact, the one time code is worthless on its own. Only your server, which holds a secret, can trade it for a token. As a result, thieves stay out. ## Which four terms should you know? Four terms come up in every OAuth setup. Once you learn these, most OAuth docs start to make sense. - **Scopes:** the specific permissions your app asks for, like “read email only”. Ask for as little as you need, because smaller asks are safer, and users trust them more. - **Access tokens:** short lived passes that do the actual work. They expire fast on purpose, so a stolen one stops working soon. - **Refresh tokens:** longer lived passes used to get new access tokens without asking the user again. Keep these very secure, because if someone steals one, they can keep getting new access tokens. - **Redirect URI:** the exact address Google sends users back to. You must register it with Google first. Otherwise, attackers could redirect the one time code to their own site and steal it. ## Is OAuth for login or permission? Strictly speaking, OAuth is about permission, not identity. It answers “what is this app allowed to do?” However, it does not answer “who is this person?” So how does “Sign in with Google” tell your app who the user is? It adds a layer on top of OAuth called **[OpenID Connect](https://openid.net/developers/how-connect-works/)** . Here is the split: - **OAuth:** gives your app permission to access things. - **OpenID Connect:** also tells your app who the user is. So when you add a login button, you are almost always using both. Also, people say “OAuth” for the whole thing, and that is fine in everyday talk. ## How do you add Google sign in to your own app? You would almost never build this by hand. Instead, ready made tools handle the hard parts for you. - **Tools that do it for you:** Auth.js (formerly NextAuth), Clerk, or Supabase Auth. - **Your client ID and secret:** Google gives you these when you register your app. In other words, think of the ID as your app’s name badge and the secret as its password. The secret goes in your environment variables, which is a locked drawer for private settings. It never goes in code you share or publish. - **The callback route:** this is the spot in your app where Google sends people back after they approve. Your tool usually creates it for you, so you just register its address with Google. - **Two addresses to register:** one for testing on your own computer and one for your live site. In fact, missing either one is the top reason sign in breaks. **How you would prompt it:** > Add “Sign in with Google” using Auth.js. Request only the email and profile scopes. Store the client secret in environment variables and register the correct redirect URLs for localhost and production. ## Which five mistakes break sign in most often? Most OAuth problems come from five slips. Check these before you ship, and use our [pre-launch security checklist](https://whattheweb.co.in/pre-launch-security-checklist/) to catch the rest. 1. **Asking for too many scopes.** Request only what you need. Wide permissions scare users and raise the damage if something leaks. 2. **Leaking the client secret.** Keep it in environment variables. Never paste it into code that goes on GitHub. 3. **Weak care of refresh tokens.** They last a long time, so treat them like passwords. 4. **Wrong or missing redirect addresses.** The address must match exactly, for both your test setup and your live site. 5. **Building it by hand.** Use Auth.js, Clerk or Supabase Auth. Hand built login is where security holes hide. ## OAuth FAQs **What does OAuth stand for?** OAuth stands for open authorization. It is an [open standard](https://oauth.net/2/) for giving an app limited access to your account. **Does OAuth share my password with the app?** No, because your password stays with the service, like Google. The app only gets a limited, temporary token. **Is OAuth the same as “Sign in with Google”?** Not exactly, because OAuth handles permission. Sign in with Google adds OpenID Connect on top, which also tells the app who you are. **What is an access token?** It is a short lived pass the app uses to reach only the things you approved. **What is a refresh token?** It is a longer lived pass used to get new access tokens without asking you again. It must be stored very securely. **What is a scope in OAuth?** It is one specific permission, like “read email only”. Good apps ask for as few scopes as possible. **What is a redirect URI?** It is the exact address where Google sends the user after they approve. You must register it first, or attackers could steal the code. **Do I need to build OAuth myself?** Almost never, since tools like Auth.js, Clerk and Supabase Auth handle it for you. **Can users take access back?** Yes, and users can remove an app’s access from their Google account settings, and the app’s pass stops working. **I build what I write about.** Try the live experiments on the [Apps page](/apps/), or look up any term in the [AI Glossary](/ai-glossary/).