OAuth 2.0 Authorization Code Flow

OAuth 2.0 authorization code flow is the recommended authentication grant type for web applications that need to access user data on behalf of users from third-party providers like Google, GitHub, Stripe, or Salesforce. It's also the foundation of "Sign in with Google/Apple/GitHub" buttons that appear across the web. Understanding the flow — the redirect URL parameters, the authorization code exchange, and the token response — is essential for implementing OAuth integrations correctly and securely. The URL in this example is the authorization redirect URL — the URL your application sends the user to when they click "Sign in with Google." Breaking down the parameters: client_id identifies your application to Google. redirect_uri is where Google sends the user after they approve access — must match one of the redirect URIs registered in your Google Cloud Console. response_type=code requests an authorization code (the "authorization code" in authorization code flow). scope defines what access your application is requesting (openid email profile). state is a random unguessable token you generate for CSRF protection. access_type=offline requests a refresh token so your app can access Google APIs even when the user isn't actively using your application. The URL parser makes these parameters readable: the URL-encoded spaces (%20) and colons (%3A%2F%2F) in redirect_uri are decoded to their actual values, making it easy to verify the callback URL is correct and that all required parameters are present. The flow after this URL: the user visits this URL, sees Google's consent screen listing the requested scopes, approves access, and Google redirects to your redirect_uri with a short-lived authorization code and your state parameter. Your callback handler verifies the state matches what you stored before generating this URL (preventing CSRF), extracts the code, and makes a POST request to Google's token endpoint to exchange the code for access and refresh tokens. PKCE (Proof Key for Code Exchange) is now required for public clients (mobile apps and SPAs) and strongly recommended for web apps. It adds a code_verifier (a random string your app generates) and code_challenge (a SHA-256 hash of the verifier) to prevent authorization code interception attacks. The token exchange POST includes the original code_verifier, which the auth server verifies against the code_challenge stored from the authorization request. Real-world scenarios: adding "Sign in with GitHub" to a developer tool so users can access their repositories; implementing Stripe Connect so marketplace sellers can authorize your platform to manage their Stripe account; integrating Google Calendar access so users can see their meetings in your application. Tips: always use HTTPS for redirect URIs in production. Store the state parameter in a secure, httpOnly cookie or server-side session — never in localStorage. Implement a short expiry on stored state values (5-10 minutes) to limit the window for CSRF attacks.

https://accounts.google.com/o/oauth2/v2/auth?client_id=123456789.apps.googleusercontent.com&redirect_uri=https%3A%2F%2Fapp.example.com%2Fauth%2Fcallback&response_type=code&scope=openid%20email%20profile&state=random_csrf_token_xyz&access_type=offline&prompt=consent