Генератор кода PKCE и вызова
Гид
Генератор кода PKCE и вызова
Генерируйте значения PKCE, соответствующие RFC 7636, прямо в вашем браузере. Укажите длину проверки (от 43 до 128 символов), и инструмент создаст криптографически случайное значение code_verifier вместе с соответствующим SHA-256 code_challenge в формате base64url, готовое для вставки в любое запрос авторизации по OAuth 2.0 или OAuth 2.1. Полезно для веб-приложений, мобильных приложений, нативных CLI и для тех, кто отладит поток авторизации с использованием PKCE в отношении поставщиков, таких как Auth0, Okta, Microsoft Entra, Google, GitHub и Keycloak.
Как использовать
- Перетащите Длина проверки ползунок — любое значение от 43 до 128 подходит; более длинные значения обеспечивают большую энтропию.
- Выберите Метод вызоваоставьте включенным
S256если ваш поставщик явно требуетplain. - Выберите Кодировка проверкиОба варианта соответствуют RFC; алфавит base64url совпадает с тем, что издают большинство клиентских библиотек.
- Нажмите СоздайтеПроверка, вызов и метод появляются мгновенно, вместе с пошаговым разбором преобразования SHA-256 → base64url.
- Скопируйте
code_challenge+code_challenge_methodв ваш/authorizeперенаправление, сохранитеcode_verifierвsessionStorageи воспроизведите его на/tokenдля завершения обмена.
Возможности
- Криптографически безопасная случайность – использует
crypto.getRandomValues()с отклонением выбора, чтобы не было смещения при использовании алфавита из 66 незарезервированных символов. - Нативный SHA-256 — вызов вычисляется с помощью браузера
SubtleCrypto.digest('SHA-256'), поэтому значения совпадают с теми, что генерирует ваш сервер авторизации. - Методы S256 и plain — оба варианта значений из RFC 7636 поддерживаются, с
code_challenge_methodвыбраны по умолчанию в соответствии с OAuth 2.1.S256— просмотрите исходную проверку, 32-байтовое шестнадцатеричное представление SHA-256 и конечный вызов в формате base64url, чтобы проверить каждое преобразование. - Пошаговое разборка Два варианта кодировки
- — выберите полный набор незарезервированных символов по RFC 7636 (A–Z, a–z, 0–9, ) или более узкий алфавит base64url, который по умолчанию используется большинством библиотек.
-,.,_,~Длина ползунка, от 43 до 128 - — оставайтесь в рамках спецификации без необходимости использовать магические числа. на каждом поле вывода, чтобы вы могли вставить его напрямую в Postman, curl или ваш код клиента.
- Копирование в один клик — ничего не отправляется на сервер. Проверка никогда не покидает вашу вкладку браузера.
- 100% клиентская сторона Что такое PKCE и почему OAuth требует его?
Часто задаваемые вопросы
-
Доказательство ключа для обмена кодом (PKCE, RFC 7636) — расширение OAuth 2.0, защищающее поток авторизации от перехвата. Клиент выбирает секрет
, вычисляет из него
code_verifierи отправляет только вызов в запросе авторизации. Когда клиент позже обменивает код авторизации на токен, он отправляет оригинальную проверку; сервер хеширует её и сравнивает с сохранённым вызовом. Даже если атакующий перехватывает код авторизации, он не может его использовать без проверки, которая никогда не покидает легитимного клиента. OAuth 2.1 делает PKCE обязательным для всех клиентов — как публичных, так и приватных.code_challengeКакова должна быть длина code_verifier и почему? -
RFC 7636 требует, чтобы проверка имела длину от 43 до 128 символов из незарезервированного набора. Минимальная граница существует потому что 43 символа в формате base64url кодируют 32 случайных байта (256 бит) — минимальная энтропия, считаемая безопасной против перебора. Более длинные проверки обеспечивают больше энтропии, но не дают реальной безопасности за пределами 256 бит. Большинство реализаций выбирают 43, 64 или 128. Выберите более длинную длину, если хотите дополнительную защиту, но будьте осторожны: некоторые устаревшие серверы отклоняют любые значения, превышающие 128, потому что строго соблюдают спецификацию.
Какова разница между методами вызова S256 и plain?
-
вызов — это хэш SHA-256 проверки, закодированный в формате base64url; при
). Без атрибута
S256вызов — это сама проверка. Метод plain не обеспечивает реальной защиты, если запрос авторизации был перехвачен — атакующий, который видит вызов, уже имеет проверку. RFC 7636 разрешает толькоplainдля клиентов, которые действительно не могут вычислять SHA-256, и OAuth 2.1 полностью запрещает его. Производственные провайдеры идентичности, такие как Auth0, Okta, Google и Microsoft Entra, отклоняютplainполностью, поэтому всегда используйтеplainесли вы не отлаживаете ограниченного встроенного клиента.plainЧто такое base64url и как он отличается от base64?S256Base64url — это URL-безопасная версия base64, определённая в RFC 4648 §5. Он заменяет -
таким образом, закодированная строка безопасна для вставки в параметр запроса, сегмент JWT или компонент пути без дополнительной экранировки. Завершающий
пояснительный символ также удаляется, потому что длина определяется контекстом. PKCE, JWT, JWE, JWS и большинство современных спецификаций веб-криптографии используют base64url именно для этих причин.
+с-и/с_Нажмите «Создать» для генерации code_verifier=Вычисленный из проверки
Установите наши расширения
Добавьте инструменты ввода-вывода в свой любимый браузер для мгновенного доступа и более быстрого поиска
恵 Табло результатов прибыло!
Табло результатов — это интересный способ следить за вашими играми, все данные хранятся в вашем браузере. Скоро появятся новые функции!
Подписаться на новости
все Новые поступления
всеОбновлять: Наш последний инструмент было добавлено 18 Июня, 2026
