ToolsHub
Developer Tools

OAuth URL Generator

Create the link that sends users to an OAuth 2.0 or OpenID Connect provider to sign in. Pick a provider, enter your client ID, redirect URI and scopes, and get a correctly encoded authorization URL with a random state, a nonce for OpenID Connect and a PKCE S256 challenge, plus the matching token-exchange request to run on your server. No client secret is asked for.

  • Runs in your browser
  • No sign-up
  • Free to use

Microsoft tenant, Auth0/Okta domain or Keycloak base URL and realm.

Public identifier from the provider’s developer console. No client secret is needed here.

Must match a URI registered with the provider exactly.

One name=value per line.

Open in new tab

How to use OAuth URL Generator

  1. Choose your provider; its endpoints are filled in.
  2. Enter the client ID and the redirect URI registered with the provider.
  3. Adjust scopes and options such as PKCE, prompt and offline access.
  4. Copy the URL to test the sign-in, and use the exchange request on your server.

OAuth URL Generator features

12 providers

Google, Microsoft, GitHub, Facebook, Apple, Discord, Slack, LinkedIn, Auth0, Okta, Keycloak or any other.

PKCE S256

Code verifier and challenge generated with a secure random source.

state and nonce

Fresh random values to protect against CSRF and replay.

Token exchange

A ready curl request for the authorization code.

Best-practice checks

Flags the implicit flow, plain-http redirects and missing PKCE.

No secrets

Client secrets are never requested and are removed if typed as a parameter.

When to use OAuth URL Generator

  • Testing a new OAuth app registration before writing code.
  • Debugging “redirect_uri_mismatch” and “invalid_scope” errors.
  • Creating a PKCE pair for a manual token exchange in development.
  • Documenting the exact sign-in request for a team.

OAuth URL Generator FAQ

What is PKCE?

Proof Key for Code Exchange. The app creates a random code_verifier, sends its SHA-256 hash (the code_challenge) in the authorization URL, and later proves possession by sending the verifier when exchanging the code. An intercepted code is useless without it.

What is the state parameter for?

It ties the response to the request. Your app stores a random state before redirecting and rejects the callback if the returned state differs, which prevents cross-site request forgery on the login flow.

Why is no client secret needed?

The authorization URL is opened in the user’s browser, so it must never contain secrets. A confidential client sends its secret only from the server to the token endpoint.

What does redirect_uri_mismatch mean?

The redirect URI in the request does not exactly match one registered with the provider, including scheme, host, port, path and trailing slash.

Should I use the implicit flow?

No. It returns tokens in the URL, where they leak into history and logs. Use the authorization code flow with PKCE, also for single-page and mobile apps.

How do I get a refresh token?

Ask for offline access: Google uses access_type=offline, most OpenID providers the offline_access scope. The option on this page adds the right one.

JWT Decoder Paste a JSON Web Token to read what is inside it. Claims such as expiry are… JWT Generator Build a signed JSON Web Token for testing an API or an authentication flow. Choose… URL Query String Generator Build a URL with parameters without worrying about encoding. Enter name and value… URL Parser Paste a URL and see every part of it laid out: scheme, user name and password… Random Token Generator Generate unguessable tokens for password-reset links, sessions, invitations, CSRF… Bearer Token Header Generator Paste an access token and get the Authorization: Bearer header, or a complete…

How the OAuth authorization request works

OAuth 2.0 lets an application act on a user’s behalf without seeing the user’s password. The application sends the user to the provider with an authorization request, the provider asks the user to sign in and approve, and then redirects back to the application with a short-lived authorization code. The application exchanges that code, from its server, for an access token and optionally a refresh token. OpenID Connect adds an ID token that tells the application who the user is.

The authorization request is just a URL with query parameters. client_id identifies the application, redirect_uri says where to send the user back and must match a registered value exactly, scope lists the permissions requested, and response_type selects the flow. Mistakes in encoding or in any of these values produce the most common OAuth errors, so a generated, correctly encoded URL is a reliable starting point.

Three random values protect the flow. state guards against an attacker injecting their own authorization response into the user’s session. nonce, for OpenID Connect, is embedded in the ID token so it cannot be replayed. PKCE binds the authorization code to the instance of the application that requested it. All three must be new for each sign-in and stored in the user’s session until the callback.

Recommendations have changed since the original specification. The implicit flow, which returned tokens directly in the URL, is deprecated and removed in OAuth 2.1, and PKCE is now recommended for every client, including server-side applications. The generator defaults to the authorization code flow with PKCE and explains the risk when you switch away from it.

Client secrets never belong in a browser, a mobile app or a URL. A confidential client, such as a server-side web application, authenticates to the token endpoint with its secret from server-side configuration; a public client, such as a single-page app, relies on PKCE alone. That is why this page has no field for a secret and drops one if it is typed in as an extra parameter.

Other useful tools