OAuth 2.0 PKCE 생성기
네트워크
PKCE(Proof Key for Code Exchange, RFC 7636)는 client_secret을 안전하게 보관할 수 없는 모든 퍼블릭 클라이언트(SPA, 모바일, 데스크톱 앱)에 권장되는 현대 OAuth 2.0 플로우입니다. 이 도구는 암호학적으로 안전한 `code_verifier`(unreserved URI 문자 43-128자)를 생성하고, `code_challenge`(S256은 SHA-256 base64url, plain은 verifier 그대로)를 유도하며, CSRF 방어용 `state`를 포함한 전체 authorization URL을 만듭니다. 함께 제공되는 `curl` 예제로 토큰 교환 단계까지 바로 처리할 수 있습니다 — 콜백 리다이렉트의 `code`만 붙여넣으면 됩니다.
사용법
- Verifier 길이 설정(기본 64, 최소 43, 최대 128).
- S256(항상 권장) 또는 plain(레거시 서버용) 선택.
- `client_id`, `redirect_uri`, `scope`, OAuth 엔드포인트 입력.
- 사용자를 authorization URL로 보내고, `?code=...` 콜백을 받으면 curl을 실행해 토큰 획득.
자주 묻는 질문
- S256 vs plain, 무엇을 써야 하나요?
- 항상 S256. plain은 verifier를 challenge로 그대로 보내기 때문에 authorization 요청이 가로채이면 보호 효과가 없습니다. S256은 SHA-256 결과만 보내고 verifier 자체는 1단계에 노출되지 않아 가로채기 공격이 훨씬 어려워집니다. RFC 7636도 S256이 가능하면 plain을 거부하라고 명시합니다.
- Verifier 문자 집합이 왜 이런가요?
- RFC 7636이 verifier 알파벳을 `[A-Z][a-z][0-9]-._~`(RFC 3986의 unreserved URI 문자)로 지정합니다. 덕분에 URL·헤더·폼 본문 어디서든 이스케이프 없이 안전하게 사용할 수 있습니다.
- `state`는 무엇인가요?
- 클라이언트가 요청마다 생성해 콜백에서 검증하는 불투명 난수 문자열입니다. CSRF 방어: 공격자가 사용자를 악의적 authorization 리다이렉트로 유도해도 앱이 기억한 `state`와 일치하지 않아 응답을 거부할 수 있습니다. 항상 사용하세요.
- 어디서 실행되나요?
- 전적으로 브라우저 안에서. Verifier는 `crypto.getRandomValues()`로, SHA-256은 `crypto.subtle.digest()`로 — 모두 Web Crypto API. 외부로 전송되지 않습니다.
관련 도구
IP 주소 분석
IPv4 또는 IPv6 입력 → 클래스·범위(사설·공인·loopback·link-local)·10진수·2진수·reverse DNS·/32 CIDR 표시.
포트 번호 참조
약 60개 표준 TCP / UDP 포트 번호 검색 가능한 치트시트 — 22(SSH)·80(HTTP)·6379(Redis)·27017(MongoDB) 등.
DNS 레코드 참조
DNS 레코드 타입 검색 가능한 치트시트 — A·AAAA·CNAME·MX·TXT·NS·SOA·PTR·SRV·CAA·DNSSEC·SVCB / HTTPS — 예시 포함.
서브넷 계산기 (IPv4 / CIDR)
IPv4 CIDR을 네트워크 주소·브로드캐스트·넷마스크·와일드카드·호스트 범위·클래스로 파싱. 이진 분석과 사설/공인 상태 표시.
User Agent 파서
User-Agent 문자열을 브라우저·엔진·OS·디바이스·CPU로 파싱. GPTBot·ClaudeBot·PerplexityBot 포함 20+ 봇 감지.
HTTP 상태 코드 레퍼런스
1xx-5xx 모든 HTTP 상태 코드 검색 — 요약·RFC·사용 시점·흔한 함정 포함.