OAuth 2.0 Authorization URL Builder
指导
OAuth 2.0 Authorization URL Builder
Assembling an OAuth 2.0 authorization request by hand is fiddly: every parameter has to be percent-encoded exactly, the PKCE code_challenge has to be a base64url-encoded SHA-256 hash of a random verifier, and the state 且 nonce values need to be unpredictable. Get one character wrong and the provider bounces you with an opaque error. This builder produces a correct, ready-to-use authorization URL from a few inputs — entirely in your browser, so secrets never leave the page.
如何使用
- Pick a provider preset (Google, GitHub, Microsoft, Okta) to auto-fill the authorization endpoint and suggested scopes, or choose Custom and paste your own endpoint.
- 输入你的
client_id和redirect_uriregistered with the provider. - Choose a response type —
code(with PKCE) is recommended for almost every modern app. - Leave PKCE and
stateenabled, add anonceif you request an ID token, and add any extra parameters such asaccess_type=offline. - 点击 Build URL, then copy the generated authorization URL. If PKCE is on, also copy the
code_verifierand keep it for the token exchange.
特征
- Provider presets – Google, GitHub, Microsoft (Entra) and Okta endpoints and scopes are filled in for you, with a Custom option for any other server.
- PKCE generation – creates a cryptographically random
code_verifierand the matching S256code_challengeusing the Web Crypto API, per RFC 7636. - State and nonce – one-click generation of unpredictable CSRF and OpenID Connect replay-protection values.
- Precise encoding – every parameter is percent-encoded to RFC 3986, with spaces rendered as
%20. - Decoded breakdown – see each query parameter and its plain value so you can verify the URL at a glance.
- 完全客户端 – nothing is sent to a server; your client secrets and verifier stay in the browser.
常问问题
-
What is the OAuth 2.0 authorization code flow?
It is the recommended way for an app to obtain access on a user's behalf. The app redirects the user to the provider's authorization endpoint; after the user consents, the provider redirects back with a short-lived authorization code, which the app then exchanges at the token endpoint for access and refresh tokens. The code never exposes long-lived credentials in the browser or URL history.
-
What is PKCE and why does it matter?
PKCE (Proof Key for Code Exchange, RFC 7636) protects the authorization code flow against interception. The client generates a random code_verifier, sends a hashed code_challenge on the authorization request, then proves possession by sending the original verifier at token exchange. It is mandatory in OAuth 2.1 and essential for public clients such as single-page and mobile apps that cannot keep a client secret.
-
What is the purpose of the state parameter?
The state parameter is an opaque, unguessable value the client sends on the authorization request and verifies when the provider redirects back. Because it is tied to the user's session, it lets the client detect and reject forged callbacks, which is the standard defense against cross-site request forgery (CSRF) on the OAuth redirect.
-
How does a nonce differ from state in OpenID Connect?
A nonce is a random value sent on the authorization request and echoed back inside the ID token's claims, letting the client confirm the token was minted for this specific request and block token replay. State protects the redirect/authorization step against CSRF, while nonce protects the issued ID token — they solve different problems and are often used together.
