PKCE 생성기

계산식은 RFC 7636 4.2절의 code_challenge = BASE64URL(SHA256(ASCII(code_verifier)))이며, base64url에는 =를 붙이지 않습니다. 생성기는 n바이트 난수를 base64url로 바꾼 뒤 필요한 길이만큼 자릅니다. 43자는 정확히 32바이트(256비트)입니다. SHA-256 자체는 해시 생성기와 같은 함수이고, 여기서는 32바이트 다이제스트를 16진수가 아니라 base64url로 표기한다는 점만 다릅니다.

RFC 7636 부록 B로 확인하기

verifier 칸에 dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk를 붙여 넣으면 E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM가 나옵니다. 부록 B의 값과 같습니다. 직접 만든 구현이 이 값을 내지 못한다면 인코딩이나 해시 대상이 잘못된 것입니다.

같은 verifier를 표준 Base64 표기 dBjftJeZ4CVP+mB92K27uhbUJU1p1r/wW1gFWFOEjXk=로 넣으면, 도구는 계산을 멈추고 *13번째 문자 ”+“는 쓸 수 없습니다. verifier에는 A–Z, a–z, 0–9와 - . _ 만 쓸 수 있습니다(RFC 7636 §4.1).*라고 표시한 뒤 base64url로 고치는 방법을 덧붙입니다. 한글 같은 비 ASCII 문자, 공백과 줄바꿈에도 각각 안내가 있고, 43128자를 벗어나면 실제 글자 수를 알려 줍니다.

네이버·카카오 로그인에서 PKCE 쓰기

네이버: 네이버 로그인 개발가이드의 3.5절 “Open ID Connect로 네이버 로그인 연동하기”에 PKCE가 나옵니다. 기존 OAuth 2.0 API와 다른 경로인 https://nid.naver.com/oauth2/authorize에 scope=openid(필수), code_challenge, code_challenge_method를 보내고, https://nid.naver.com/oauth2/token에 “PKCE로 동작하는 경우” code_verifier를 추가합니다. 표에 적힌 code_challenge_method의 기본값은 S256으로, 매개변수가 없으면 plain으로 보는 RFC 7636 4.3절과 다릅니다. 다른 서버로 옮길 때를 생각해 S256을 항상 명시하는 편이 안전하며, 이 도구의 인가 URL도 그렇게 만듭니다.

카카오: OIDC 메타데이터(https://kauth.kakao.com/.well-known/openid-configuration)는 code_challenge_methods_supported: ["S256"]을 반환하지만, 카카오 로그인 REST API 문서의 “인가 코드 받기” 요청 매개변수 표(client_id, redirect_uri, response_type, scope, prompt, login_hint, service_terms, state, nonce)에는 code_challenge가 없습니다(2026-10-01 확인). PKCE에 기대기 전에 테스트 앱으로 실제 동작을 확인하세요. 카카오의 scope는 쉼표로 구분하는데, 이 도구는 openid,profile_nickname처럼 쉼표로 적어도 openid를 인식해 nonce를 붙입니다. state는 요청마다 고유해야 한다고 문서에 적혀 있으니, 도구가 만드는 무작위 값을 그대로 쓸 수 있습니다.

인가 URL이 의도대로 만들어졌는지는 URL 분석기로 매개변수를 하나씩 펼쳐 확인할 수 있습니다.

challenge가 맞지 않을 때

code_challenge 대조를 펼쳐 앱이 실제로 보낸 값을 붙여 넣습니다. 부록 B의 verifier 기준으로 다음과 같이 판정합니다.

마지막 경우는 직접 구현할 때 자주 생깁니다. 난수 바이트를 보관해 두었다가, 실제로 보낸 43자 문자열 대신 바이트를 해시하는 실수입니다. plain을 선택한 상태에서 S256 결과를 붙여 넣으면 code_challenge_method=S256을 보내라고 안내합니다. 표준 Base64와 base64url의 차이는 Base64 인코드 / 디코드에서 두 알파벳을 비교해 볼 수 있습니다.

코드로 같은 값 구하기

부록 B의 verifier에 대해 아래 세 가지는 모두 E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM를 돌려줍니다. 이 페이지의 테스트가 실제로 실행합니다.

// 브라우저와 Node.js 20 이상(Web Crypto)
const base64url = (bytes) =>
  btoa(String.fromCharCode(...bytes)).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');

function createVerifier() {
  return base64url(crypto.getRandomValues(new Uint8Array(32))); // 43자
}

async function createChallenge(verifier) {
  const digest = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(verifier));
  return base64url(new Uint8Array(digest));
}

import base64
import hashlib
import secrets


def create_verifier() -> str:
    return secrets.token_urlsafe(32)  # 32바이트 난수 -> 43자


def create_challenge(verifier: str) -> str:
    digest = hashlib.sha256(verifier.encode("ascii")).digest()
    return base64.urlsafe_b64encode(digest).rstrip(b"=").decode("ascii")

package main

import (
	"crypto/rand"
	"crypto/sha256"
	"encoding/base64"
)

func createVerifier() string {
	b := make([]byte, 32)
	rand.Read(b)
	return base64.RawURLEncoding.EncodeToString(b) // 43자
}

func createChallenge(verifier string) string {
	sum := sha256.Sum256([]byte(verifier))
	return base64.RawURLEncoding.EncodeToString(sum[:])
}

로그인 뒤 ID 토큰에 들어 있는 nonce는 JWT 디코더로 확인할 수 있습니다.

다른 온라인 PKCE 도구와의 차이

2026-10-01 데스크톱 Chromium에서, 생성·대조하는 동안 페이지가 보낸 fetch, XMLHttpRequest, sendBeacon을 기록해 확인했습니다.

• ToolBada(OAuth PKCE 생성기)와 encode64 한국어판: 브라우저 안에서 생성하지만, 가지고 있는 verifier나 challenge를 대조하는 기능은 없습니다.
• Elysia Tools: 생성과 검증 모두 모드, verifier, challenge를 JSON으로 api.elysiatools.com에 보내고 서버가 돌려준 결과를 보여 줍니다.
• tonyxu-io.github.io/pkce-generator: 브라우저 안에서 동작하고 부록 B 값도 맞지만, 입력을 검증하지 않습니다. 42자, + / =가 섞인 값, 한글, 빈칸 모두 challenge가 나옵니다.

이 도구는 붙여 넣은 verifier를 RFC 문법으로 한 글자씩 검사해 문제 위치를 알려 주고, challenge가 맞지 않을 때 원인의 종류까지 보여 줍니다. verifier는 탭 밖으로 나가지 않습니다.

제한

• 방식은 RFC 7636이 정의한 S256과 plain뿐입니다. 생성하는 verifier는 base64url의 64개 문자만 쓰므로, 똑같이 유효한 .와 ~는 나오지 않습니다.
• 엔트로피는 이 페이지에서 생성한 verifier에만 표시합니다. 붙여 넣은 verifier는 형식만 판정할 수 있고 무작위성은 알 수 없습니다.
• 인가 서버에 연결하지 않으므로 토큰 교환을 대신할 수 없습니다. cURL은 퍼블릭 클라이언트 기준이며, 컨피덴셜 클라이언트는 클라이언트 인증을 더해야 합니다.
• 제공자별 규칙(네이버의 기본값 S256 등)은 검사하지 않습니다.
• verifier는 인가 요청 한 번마다 새로 만드세요. 고정된 verifier는 보호 효과가 없고, RFC 9700 2.1.1절도 서버가 고정값을 찾아 거부하도록 권합니다.