OAuth2 URL Builder

Just Build Me the URL

You've registered your client. You have the client_id, the redirect_uri, the scopes you want. You just need a URL to paste into a browser to test the flow. URL construction sounds trivial, but escaping is fiddly: scope strings with spaces need to be URL-encoded, redirect_uris with query params need to be encoded twice (once for the original URI, again as a parameter value), and "did I miss a parameter?" is hard to verify by eye. This tool handles it.

The Parameters and What They Mean

response_type (required). Tells the auth server what kind of credential to return.

• code, return an authorization code (you exchange it for tokens later). The 99% case.
• token, return an access token directly (implicit flow; deprecated).
• id_token, OIDC, return an id_token (no access token).
• Combinations like code id_token, hybrid OIDC flows.

client_id (required). Your app's public identifier with the provider. Issued at registration. Safe to include in URLs, by design, public information.

redirect_uri (required). Where the provider sends the user after auth. MUST exactly match one of the URIs registered with the provider. Trailing slashes matter. Schemes matter (http vs https). Localhost-with-port matters.

scope (often required). Space-separated list of permissions you're requesting. openid email profile for basic OIDC; provider-specific strings for API access. Encoded as a single URL-encoded value with %20 between scopes (or +, both work).

state (effectively required). Opaque random value tied to the user's session. Validated on the callback to prevent CSRF. Generate per-request, never reuse.

nonce (OIDC only). Random value the provider embeds in the id_token claims. Validates that the token came from your auth request, not replayed. Required for OIDC implicit/hybrid flows; recommended for code flow.

code_challenge (PKCE). Base64URL-encoded SHA-256 of your code_verifier. Required for OAuth 2.1.

code_challenge_method (PKCE). S256 (do this) or plain (don't).

prompt (OIDC). Hint to the auth server: none (fail if not already authenticated), login (force re-authentication), consent (force re-consent), select_account (show account picker).

login_hint (OIDC). Pre-fill the username field. user@example.com.

max_age (OIDC). Maximum allowable age of the user's authentication, in seconds. Forces re-auth if older.

Provider URL Patterns

Each provider has a fixed authorization endpoint; you append parameters as query string.

Google:
https://accounts.google.com/o/oauth2/v2/auth?...

GitHub:
https://github.com/login/oauth/authorize?...

Microsoft Entra ID:
https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize?... (note tenant in the path)

Auth0:
https://<domain>.auth0.com/authorize?...

Okta:
https://<domain>.okta.com/oauth2/default/v1/authorize?...

Apple:
https://appleid.apple.com/auth/authorize?...

Discord:
https://discord.com/api/oauth2/authorize?...

Slack:
https://slack.com/oauth/v2/authorize?...

Provider-specific parameters (like Google's access_type=offline for refresh tokens, or Microsoft's prompt=select_account) are added the same way.

Encoding: The Detail That Bites

URLs use application/x-www-form-urlencoded. The rules:

• Space: Encoded as %20 or +. Both work in query strings.
• Special chars (&, =, ?, #, /, :): URL-encoded (%26, %3D, etc.).
• Unreserved chars (A-Z a-z 0-9 - . _ ~): not encoded.

The tricky case: when redirect_uri itself contains a query string. E.g., your callback is https://app.example.com/cb?env=staging. The redirect_uri parameter value must encode the inner ? and =:

A common bug: encoding once (so the inner ? survives), causing the auth server to interpret it as a separate URL parameter. The URL builder handles this correctly.

Common Patterns

Public client (SPA, mobile, CLI):
response_type=code, client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256. No client_secret anywhere.

Confidential client (server-side web app):
Same as above plus the server sends client_secret during the token exchange (not in the URL).

OIDC for sign-in only:
scope=openid email profile. After exchange, validate the id_token and use its sub claim as the user identifier.

Refresh-token-enabled (Google specifically):
Add access_type=offline and prompt=consent to force the consent screen so Google issues a refresh token. Without prompt=consent, Google often returns a refresh token only on the first consent, not subsequent silent re-auths.

Multi-tenant Microsoft:
Use /common instead of a specific tenant ID in the path. Validate the issuer claim in the resulting id_token.

Where URL Building Stops

This tool builds the URL. It doesn't:

• Execute the redirect (you click the URL or paste it into a browser).
• Exchange the code for tokens (server-side step, needs token endpoint).
• Validate tokens (signature, claims).
• Refresh tokens.
• Implement logout (end_session_endpoint for OIDC).

For those, use a library (@auth0/auth0-spa-js, oidc-client-ts, next-auth, your provider's official SDK). The URL builder is the "I want to verify what my library is constructing" or "I want to manually test the redirect" tool.

Testing Manually

The workflow:

1. Build the URL in this tool.
2. Paste in a browser, hit Enter.
3. Auth server prompts you to log in / consent.
4. Browser redirects to your redirect_uri with ?code=... and ?state=....
5. Verify the state matches what you set.
6. Hit the token endpoint with curl or Postman to exchange the code.
7. Inspect the returned tokens.

Quick way to verify your client config is correct without writing any application code.

Privacy

URL construction is local string manipulation. Client IDs, redirect URIs, internal scope names, all stay in the tab. Open DevTools Network: zero outbound requests. Provider calls only happen when you click or paste the constructed URL.