¿Odias los anuncios? Ir Sin publicidad Hoy 

OAuth 2.0 Authorization URL Builder

DesarrolladorRedesSeguridad

APORTE

Provider & Endpoint

X-Hub-Signature-256

Picking a preset fills the authorization endpoint and suggested scopes. Choose Custom for any other OAuth 2.0 / OpenID Connect server.

Authorization Endpoint

The provider's /authorize URL. Auto-filled for presets; edit freely (e.g. replace the Microsoft/Okta tenant or domain).

Request Parameters

Client ID

The public client identifier issued by the provider. Safe to expose in the URL.

Redirect URI

Must exactly match a redirect URI registered with the provider.

Tipo de respuesta

Use code (Authorization Code flow) for anything modern. Implicit (token / id_token) is legacy and discouraged.

Scopes

Space-separated list of scopes. Presets suggest common values; edit as needed.

Security Parameters

Add PKCE (code_challenge)

PKCE Method

S256 (SHA-256) is required by OAuth 2.1 and every modern provider. Use plain only for legacy testing.

Add state parameter (CSRF protection)

Add nonce parameter (OpenID Connect)

Extra Parameters

Optional. One key=value pair per line. Added verbatim (URL-encoded) to the query string.

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

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 y 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.

Cómo Usar

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.
Introduzca su client_id y el redirect_uri registered with the provider.
Choose a response type — code (with PKCE) is recommended for almost every modern app.
Leave PKCE and state enabled, add a nonce if you request an ID token, and add any extra parameters such as access_type=offline.
Haz clic en Build URL, then copy the generated authorization URL. If PKCE is on, also copy the code_verifier and keep it for the token exchange.

Características

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_verifier and the matching S256 code_challenge using 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.
Totalmente del lado del cliente – nothing is sent to a server; your client secrets and verifier stay in the browser.

 Preguntas frecuentes

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.