OAuth 2.0 is the protocol behind "Login with Google" and "Connect with GitHub." This guide explains the flows, tokens, and terminology without the jargon — and when to use which grant type.
In this guide
OAuth 2.0 is an authorization protocol — it lets users grant your app limited access to their account on another service (Google, GitHub, Stripe) without giving you their password. When a user clicks "Login with Google," Google authenticates the user and then gives your app a token. Your app uses that token to access specific data (like the user's email) but cannot see their Google password or access data beyond what was granted.
1) Your app redirects the user to the provider's authorization URL with your client_id, requested scopes, and a redirect_uri. 2) The user authenticates with the provider and approves your requested permissions. 3) The provider redirects back to your redirect_uri with a short-lived authorization code. 4) Your server exchanges that code for an access token (and optionally a refresh token) via a back-channel POST request. 5) Your app uses the access token to make API calls on the user's behalf.
Access tokens are short-lived credentials (typically 1 hour) that authenticate API requests: Authorization: Bearer <token>. Refresh tokens are long-lived credentials used to get new access tokens without requiring the user to log in again. Store access tokens in memory (never localStorage). Store refresh tokens in httpOnly cookies or secure server-side storage. Never log tokens or include them in URLs — they appear in access logs.
OAuth 2.0 handles authorization (what can your app do). OpenID Connect (OIDC) is a layer on top of OAuth 2.0 that handles authentication (who is the user). OIDC adds an ID token — a JWT containing user identity information (name, email, profile picture). When you use "Login with Google," you are using OIDC, not raw OAuth 2.0. Libraries like NextAuth.js and Auth0 implement OIDC so you do not have to manage these flows manually.
For server-to-server API calls where there is no user involved, use the Client Credentials flow: your server sends its client_id and client_secret directly to the authorization server and receives an access token. No user redirect required. This is used for: cron jobs calling an API, microservices authenticating with each other, and automated integrations. Rotate client secrets regularly and store them as environment variables, never in code.
Need Help?
Our engineering team handles implementations like this every week. Get a free scoping call — we will tell you exactly what it takes and what it costs.
Book a free callCompetitive Intelligence
Efficiency Modeling
© 2026 NexWorldTech — Built for Global Dominance.