Skip to content
UniKit

OAuth2 flow builder

Build an OAuth 2.0 authorization URL with response_type, client_id, redirect_uri, scope, state, nonce and PKCE (code_challenge / S256), plus flow walkthroughs and sample code for authorization code, implicit and client credentials.

Runs in your browserEvery computation happens in your browser — your data never leaves this device.

Flow

Parameters and sample code are assembled locally — no authorization or token request is ever made, SHA-256 runs in WebCrypto and the verifier never leaves the page.

Authorization URL

Built authorization link
https://auth.example.com/authorize?response_type=code&client_id=unikit-demo&redirect_uri=https%3A%2F%2Funikit.cc%2Foauth%2Fcallback&scope=openid%20profile%20email&state=f8a1c2d3e4b5a6978877665544332211&nonce=n-0S6_WzA2Mj&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256
Query parameters
response_typecode
client_idunikit-demo
redirect_urihttps://unikit.cc/oauth/callback
scopeopenid profile email
statef8a1c2d3e4b5a6978877665544332211
noncen-0S6_WzA2Mj
code_challengeE9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
code_challenge_methodS256

Flow walkthrough

  1. The client creates code_verifier and code_challenge, then sends the browser to the authorization endpoint (response_type=code).
  2. The user signs in and consents; the browser returns to redirect_uri with a code.
  3. The server exchanges code + code_verifier at the token endpoint for an access_token and refresh_token.
  4. Send the access_token in an Authorization: Bearer header and use the refresh_token to renew it.

Parameter checks

All parameters are present and PKCE plus state follow the specs.

Sample code

// 授权码 + PKCE：verifier 只保存在本地，challenge 才发给授权服务器
const verifier = 'YOUR_CODE_VERIFIER';
const digest = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(verifier));
const codeChallenge = base64UrlEncode(new Uint8Array(digest));
// code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM (S256)
window.location.href = 'https://auth.example.com/authorize?response_type=code&client_id=unikit-demo&redirect_uri=https%3A%2F%2Funikit.cc%2Foauth%2Fcallback&scope=openid%20profile%20email&state=f8a1c2d3e4b5a6978877665544332211&nonce=n-0S6_WzA2Mj&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256';
// 回调拿到 code 后，在服务端用 code + verifier 换 token
// POST https://auth.example.com/token  grant_type=authorization_code
curl for the token exchange
curl -X POST 'https://auth.example.com/token' \ \
  -H 'content-type: application/x-www-form-urlencoded' \ \
  -d 'grant_type=authorization_code&code=$CODE&redirect_uri=https://unikit.cc/oauth/callback' \ \
  -d 'client_id=unikit-demo' \
  -d 'code_verifier=$VERIFIER'

What this tool does

  • Building a third-party sign-in? Assemble the authorization link first and confirm response_type, scope, state and redirect_uri before pasting it into code.
  • Roll out PKCE with one click: generate a code_verifier plus its S256 code_challenge, keep the verifier locally and send only the challenge.
  • Compare the three flows — authorization code (server-side exchange), implicit (deprecated) and client credentials (no user) — each with a walkthrough and a curl example.

Example

Input

flow Authorization Code; endpoint https://auth.example.com/authorize; client_id unikit-demo; redirect_uri https://unikit.cc/oauth/callback; scope openid profile email; state f8a1c2d3e4b5a6978877665544332211; nonce n-0S6_WzA2Mj; code_challenge_method S256

Output

https://auth.example.com/authorize?response_type=code&client_id=unikit-demo&redirect_uri=https%3A%2F%2Funikit.cc%2Foauth%2Fcallback&scope=openid%20profile%20email&state=f8a1c2d3e4b5a6978877665544332211&nonce=n-0S6_WzA2Mj&code_challenge=...&code_challenge_method=S256

The parameter order is fixed (response_type → client_id → redirect_uri → scope → state → nonce → code_challenge) and spaces are encoded as %20.

Frequently asked questions

How is the S256 code_challenge computed?

Generate a code_verifier of 43–128 unreserved characters, then compute base64url(SHA-256(verifier)). This tool digests with the browser WebCrypto while the pure module only does base64url, so the unit tests can verify it against the public RFC 7636 appendix B vector (verifier dBjftJeZ… → challenge E9Melhoa2Ow…).

What does state actually protect against?

CSRF: store a random state in the session and compare it on the callback, so forged authorization responses are rejected. Use at least 16 random characters — never a timestamp or user id.

Is the implicit flow still usable?

It works but is not recommended: the token lands in the URL fragment where it leaks into history and logs, and there is no refresh_token. OAuth 2.1 removes it, so use authorization code with PKCE for anything new.

Why is there no authorization URL for client credentials?

No user authorizes anything — the client exchanges its own credentials at the token endpoint. The client_secret belongs on the server; a secret shipped to the browser is effectively public.

Does the tool call the authorization server?

No. It assembles parameters, generates sample code and runs rule checks. It never makes an authorization or token request and never sends your client_id anywhere.

Keywords：oauth2oauth2 flowauthorization urlpkcecode challengeauthorization codeOAuth2 流程授权链接生成PKCE 生成授权码模式client credentialsstate nonce

Related tools

CORS config generatorNetworkhtpasswd generatorNetworkHTTP request builderNetworkIPv4 address converterNetworkIPv4 range expanderNetworkIPv4 subnet calculatorNetwork