広告が嫌いですか? 行く広告なし今日 

PKCE Code Verifier & Challenge Generator

開発者安全

広告削除する？

入力

出力

クライアント側

広告削除する？

ガイド

PKCE Code Verifier & Challenge Generator

Generate RFC 7636-compliant PKCE values right in your browser. Pick a verifier length (43–128 characters), and the tool produces a cryptographically random code_verifier together with the matching SHA-256 code_challenge in base64url form, ready to drop into any OAuth 2.0 or OAuth 2.1 authorization request. Useful for SPAs, mobile apps, native CLIs, and anyone debugging an authorization-code-with-PKCE flow against providers like Auth0, Okta, Microsoft Entra, Google, GitHub, and Keycloak.

使用方法

をドラッグして Verifier Length slider — anything from 43 to 128 works; longer values give more entropy.
を選択します Challenge Method. Leave it on S256 unless your provider explicitly requires plain.
[ブラウザのchrome]を選択し、 Verifier Charset. Both options are RFC-compliant; the base64url alphabet matches what most OAuth client libraries emit.
クリック生成. The verifier, challenge, and method appear instantly, along with a step-by-step breakdown of the SHA-256 → base64url transformation.
Copy the code_challenge + code_challenge_method into your /authorize redirect, store the code_verifier で sessionStorage, and replay it on /token to finish the exchange.

機能

Cryptographically secure randomness – 使用 crypto.getRandomValues() with rejection sampling so there is no modulo bias on the 66-character unreserved alphabet.
Native SHA-256 – the challenge is computed via the browser’s SubtleCrypto.digest('SHA-256'), so values match what your authorization server will produce.
S256 and plain methods – both code_challenge_method values from RFC 7636 are supported, with S256 selected by default per OAuth 2.1.
ステップ・バイ・ステップの解説 – see the raw verifier, the 32-byte SHA-256 hex digest, and the final base64url challenge so you can audit each transformation.
Two charset options – pick the full RFC 7636 unreserved set (A–Z, a–z, 0–9, -, ., _, ~) or the narrower base64url alphabet that most libraries default to.
Length slider, 43 to 128 – stay within the spec without juggling magic numbers.
ワンクリックコピー on every output field so you can paste straight into Postman, curl, or your client code.
100%クライアントサイド – nothing is sent to a server. The verifier never leaves your browser tab.

 よくある質問

What is PKCE and why does OAuth need it?

Proof Key for Code Exchange (PKCE, RFC 7636) is an OAuth 2.0 extension that protects the authorization code flow against interception. The client picks a secret code_verifier, derives a code_challenge from it, and sends only the challenge on the authorize request. When the client later redeems the authorization code at the token endpoint, it sends the original verifier; the server hashes it and compares it to the stored challenge. Even if an attacker intercepts the authorization code, they cannot exchange it without the verifier, which never leaves the legitimate client. OAuth 2.1 makes PKCE mandatory for all clients, public or confidential.
How long should a code_verifier be and why?

RFC 7636 requires the verifier to be between 43 and 128 characters from the unreserved set. The lower bound exists because 43 base64url characters encode 32 random bytes (256 bits) — the minimum entropy considered safe against brute force. Longer verifiers give more entropy but offer no real security benefit past 256 bits. Most reference implementations pick 43, 64, or 128. Choose the longer end if you want defense in depth, but be aware some legacy servers reject anything past 128 because they enforce the spec strictly.
What is the difference between the S256 and plain challenge methods?

の場合、クッキーは S256 the challenge is the base64url-encoded SHA-256 hash of the verifier; with plain the challenge is the verifier itself. The plain method offers no real protection if the authorization request is intercepted — an attacker who sees the challenge already has the verifier. RFC 7636 only allows plain for clients that genuinely cannot compute SHA-256, and OAuth 2.1 disallows it entirely. Production identity providers like Auth0, Okta, Google, and Microsoft Entra reject plain outright, so always use S256 unless you are debugging a constrained embedded client.
What is base64url and how does it differ from base64?

Base64url is a URL-safe variant of base64 defined in RFC 4648 §5. It replaces + は迅速なパスだが、属性の扱いが不一致であり、エッジケースでデータを失う可能性がある。SOAPレスポンスのプロダクション用途では、 - と / は迅速なパスだが、属性の扱いが不一致であり、エッジケースでデータを失う可能性がある。SOAPレスポンスのプロダクション用途では、 _ so the encoded string is safe to drop into a query parameter, JWT segment, or path component without further escaping. Trailing = padding is also stripped because the length is implied by the surrounding context. PKCE, JWT, JWE, JWS, and most modern web crypto specs use base64url for exactly these reasons.