PKCE Challenge Generator: สร้าง code_verifier และ S256 code_challenge สำหรับ OAuth 2.0 ในคลิกเดียว
เครื่องมือ PKCE Challenge Generator ฟรี สร้างคู่ code_verifier และ code_challenge แบบ S256 ตามมาตรฐาน RFC 7636 ทำงานใน browser ล้วน ๆ ผ่าน Web Crypto API ไม่ต้องติดตั้ง ไม่มี server
Table of Contents
PKCE Challenge Generator: สร้าง code_verifier และ S256 code_challenge สำหรับ OAuth 2.0 ในคลิกเดียว
ใครที่เคย wire up OAuth 2.0 ให้ SPA หรือ mobile app น่าจะเคยเจอ PKCE — Proof Key for Code Exchange — extension ตามมาตรฐาน RFC 7636 ที่ใช้ harden authorization code flow หลักการคือเราสร้าง code_verifier ที่ random แบบ cryptographically secure แล้ว derive เป็น code_challenge ส่ง challenge ไปพร้อม authorization request แล้วค่อยเปิดเฉยย verifier ตอนเรียก token endpoint แต่ถ้า encoding พลาดแม้ตัวเดียว เช่น มี + หรือ = ปนมาจาก Base64 ธรรมดาแทนที่จะเป็น Base64URL server จะ reject การ exchange ทันทีด้วย error แบบ invalid_code_verifier
เพราะอย่างนั้นเราเลยทำ PKCE Challenge Generator ฟรี ๆ ขึ้นมา มันสร้าง verifier สด ๆ จาก CSPRNG ของ browser (crypto.getRandomValues) คำนวณ S256 challenge ผ่าน crypto.subtle.digest แล้วส่งมอบคู่ values ที่ copy-paste ได้ทันที ทุกอย่างทำงาน client-side 100% ไม่มี secret ใดออกจากเครื่องคุณ
บทความนี้จะพาไล่ดู feature ของ tool ขั้นตอนการใช้งานทีละ step และทฤษฎี PKCE ที่จะทำให้ทุก option — method, length, charset — รู้สึก make sense ทั้งหมด
ทำไมต้องใช้ PKCE Challenge Generator
- Random แบบ cryptographic ทุกครั้ง — verifier ทุกตัวมาจาก CSPRNG ของ browser ผ่าน crypto.getRandomValues ไม่ใช่ Math.random ดังนั้น entropy เต็มรูปแบบ ทายไม่ได้แน่นอน
- Derive S256 ตรงตาม spec — challenge คำนวณเป็น BASE64URL(SHA256(code_verifier)) ผ่าน Web Crypto API (crypto.subtle.digest) ซึ่งเป็น transform ที่ RFC 7636 กำหนดเป๊ะ ไม่ต้องพึ่ง crypto library ของพรรคพวก
- ไม่มีอะไรออกจาก browser — tool ทำงาน client-side ล้วน ๆ ไม่มี server ไม่มี network call ไม่มี log ปลอดภัยแม้ใช้กับ OAuth client ของ production
- Compliant ตั้งแต่ถูกสร้าง — ความยาวถูกจำกัดที่ 43-128 ตัวอักษรตาม RFC และ output ใช้เฉพาะ charset [A-Za-z0-9-._~] ที่อนุญาต ทำให้ไม่มีทางสร้างคู่ที่ server มาตรฐาน reject
- เอา verifier ตัวเองมาได้ — paste code_verifier เดิมเข้ามาแล้วเห็น S256 challenge ได้ทันที เหมาะกับการ debug flow ที่พังตอน token endpoint
- Copy ปุ๊บ ได้ปั๊บ — ปุ่ม copy คลิกเดียวสำหรับทั้งสองค่า พร้อม example authorization URL ที่ใส่ challenge ลง query string เรียบร้อยแล้ว
Key Features
| Feature | รายละเอียด |
|---|---|
| Verifier generation | สร้าง code_verifier แบบ CSPRNG ผ่าน crypto.getRandomValues |
| Challenge methods | รองรับทั้ง S256 (แนะนำ) และ plain (challenge = verifier) |
| S256 derivation | BASE64URL(SHA256(code_verifier)) ผ่าน crypto.subtle.digest |
| Length control | slider ปรับความยาว 43-128 ตัวอักษร regenerate แบบ real-time |
| Custom verifier | paste verifier ของตัวเอง พร้อม validate ตาม charset ของ RFC 7636 |
| Copy buttons | คลิกเดียว copy ได้ทั้ง code_verifier และ code_challenge |
| Example URL | authorization request ที่มี code_challenge และ code_challenge_method=S256 พร้อมใช้ |
| Privacy | ทำงานใน browser ล้วน ๆ ไม่มี server ไม่มีการส่งข้อมูลออกไป |
- slider regenerate คู่ values ทันทีระหว่างลาก — สะดวกมากเวลา provider ระบุความยาว verifier ที่ต้องการมาเป็นพิเศษ
- โหมด custom verifier จับ illegal character ก่อนที่ authorization server จะจับซะอีก ส่วน example URL ชี้รูปร่างของ request ที่ถูกต้องให้เห็นชัด ๆ: https://auth.example.com/authorize?response_type=code&client_id=YOUR_ID&code_challenge=...&code_challenge_method=S256&redirect_uri=...
วิธีใช้งาน
- เปิด PKCE Challenge Generator — verifier และ S256 challenge ใหม่พร้อมใช้ทันทีที่หน้าเว็บโหลดเสร็จ
- เลือก method — ใช้ S256 ไว้ก่อน เว้นแต่ server ของคุณไม่รองรับจริง ๆ ส่วน plain มีไว้สำหรับ legacy system เท่านั้น
- ปรับความยาว — ลาก slider ระหว่าง 43 ถึง 128 ตัวอักษร คู่ values จะ regenerate ให้ทันที
- Copy ค่าทั้งสอง — เอา code_challenge ไปใส่ใน authorization request แล้วเก็บ code_verifier ไว้สำหรับ token exchange
- Wire เข้า flow ของคุณ — ส่ง code_challenge กับ code_challenge_method=S256 ใน authorization URL เก็บ verifier ไว้ฝั่ง client แล้วค่อยยื่นตอน exchange code เป็น token
ทำความเข้าใจ PKCE
PKCE เอามาปิดช่องโหว่ใหญ่สุดของ authorization code flow แบบเดิม: code ต้องเดินทางผ่าน front channel ใน browser code จะไป landing ใน redirect URL ส่วนบน mobile app ที่เจตนาร้ายสามารถ register custom URI scheme เดียวกันแล้วดัก code ได้ ใครก็ตามที่ขโมย code ได้จะแลกเป็น token ได้เลย — เว้นแต่ code นั้นจะผูกกับ secret ที่มีแค่ legitimate client ถืออยู่
secret ตัวนั้นก็คือ code_verifier: string สุ่ม entropy สูงความยาว 43-128 ตัวอักษรจาก charset [A-Za-z0-9-._~] จาก verifier เรา derive เป็น code_challenge:
S256: code_challenge = BASE64URL(SHA256(code_verifier)) plain: code_challenge = code_verifier
handshake ทำงาน 4 จังหวะ app ส่ง code_challenge กับ code_challenge_method ไปพร้อม authorization request server เก็บ challenge เอาไว้แล้วออก authorization code ให้ จากนั้น app ยื่น code พร้อม code_verifier ตัวจริงที่ token endpoint สุดท้าย server ก็ hash verifier ที่รับมาแล้วเทียบกับ challenge ที่เก็บไว้ — match เท่านั้นถึงจะได้ token ดังนั้น hacker ที่มีแค่ code จะไม่ได้อะไรเลย
ทำไมต้อง prefer S256? เพราะ challenge ไปกับ query parameter ถ้าใช้ plain ตัว verifier เองจะถูก broadcast ไปบน front channel เดียวกัน ซึ่งเท่ากับฆ่าแผนการตาย ส่วน S256 มีแค่ one-way hash ที่ข้ามสาย plain ยังอยู่ใน RFC เพราะ client บางตัว hash ไม่ได้ แต่ browser ยุคนี้กับ framework หลัก ๆ ทำได้หมด
ตัวเลข 43-128 กับ charset ก็มีที่มาเหมือนกัน 43 ตัวอักษรของ Base64URL encode ได้ 256 bits พอดี — คือ entropy ขั้นต่ำที่ RFC 7636 ถือว่าสุ่มเดาไม่ได้ และ 128 ตัวอักษรทำให้รูป encoded ไม่เกิน 96 bytes ส่วน charset คือ unreserved set ของ RFC 3986 ที่รอดจากการขนส่งแบบ query string โดยไม่ต้อง percent-encoding หรือมีปัญหา canonicalization ระหว่าง client กับ server
Use Cases การใช้งานจริง
Single-Page Application (SPA)
SPA เป็น public client ที่เก็บ client secret ไม่ได้ ดังนั้น PKCE คือแนวป้องกันหลัก — draft ของ OAuth 2.1 ถึงขั้นบังคับเลย Generate คู่นึง เก็บ code_verifier ไว้ใน memory (ไม่ใช่ localStorage) ส่ง challenge ไปกับ redirect แล้วปิด deal ด้วย fetch
Mobile App OAuth
Native app authenticate ผ่าน external browser แล้วกลับมาด้วย redirect scheme — ทั้งคู่เสี่ยง interception บน OS ที่ใช้ร่วมกัน verifier ที่สร้างใหม่ทุก request บนเครื่องผู้ใช้ทำให้ code ที่ถูกขโมยไปกลายเป็นขยะ และ example URL ของ tool ก็เป็น template ให้ deep-link handler ของคุณได้เลย
CLI และ Backend Token Exchange
Headless client, CI pipeline และ script ที่ใช้ device flow ก็ได้ประโยชน์เหมือนกัน Generate คู่ไว้ล่วงหน้า ส่ง challenge ไปกับ device-authorization request แล้วเก็บ verifier ไว้ใน local variable จนกว่า polling จะได้ code กลับมา
Debug code_verifier เดิม
เวลา exchange พังด้วย invalid_code_verifier ปัญหาส่วนใหญ่คือ encoding: ใช้ Base64 ธรรมดาแทน Base64URL, padding หาย หรือ string ถูกตัดขาด paste verifier ตัวที่สงสัยเข้าช่อง custom input แล้วเทียบ S256 output ของ tool กับ challenge ที่ app ส่งไป — จุดที่ mismatch เจอทันที ส่วน charset validation ก็ flag illegal character ให้เห็นในตำแหน่งเดียวกัน
Best Practices
- เลือก S256 เสมอ เว้นแต่ legacy server hash ไม่ได้จริง ๆ — plain เปิดเปลือกให้ verifier โชว์บน front channel
- Generate คู่ใหม่ทุก authorization request — ห้าม reuse verifier ข้าม session หรือข้าม user เด็ดขาด
- ห้าม log verifier — ให้ถือเป็น single-use password เพราะมันคือหลักฐานยืนยันตัว client ของคุณ
- เก็บไว้ใน memory เท่านั้น — ใช้ verifier ให้จบภายใน flow เดียว เลี่ยงการ persist ลง storage ที่ XSS อ่านได้
- อย่าละเมดขอบเขต — อยู่ในช่วง 43-128 ตัวอักษรและ charset [A-Za-z0-9-._~] tool บังคับทั้งคู่อยู่แล้ว ของที่ copy ออกมาเป็น compliant หมด
- Test รอบเต็ม — บาง provider จะ reject authorization request ที่ไม่ส่ง code_challenge_method มาด้วย
พร้อมสร้าง PKCE pair แรกของคุณหรือยัง?
เลิกคิดสมการ Base64URL padding กับการอ่าน RFC ซ้ำ ๆ ได้แล้ว PKCE Challenge Generator สร้างคู่ที่ comply กับ RFC 7636 ในคลิกเดียว — random จาก CSPRNG, hash S256 ใน browser ของคุณ ไม่มีทางถูกส่งไปไหน เปิด tool, copy ค่า แล้วกลับไป build auth flow ต่อได้เลย
Related Tools You Might Like:
Happy building!
คำถามที่พบบ่อย
ถ: code_verifier กับ code_challenge ต่างกันยังไง? ตอบ: verifier คือ string สุ่มลับที่ client สร้างขึ้น ส่วน challenge คือค่าที่ derive มาจากมัน — hash SHA-256 แล้ว encode Base64URL ในกรณี S256 — ที่ส่งไปพร้อม authorization request ตัว verifier จะเปิดเผยทีหลังเฉพาะที่ token endpoint เท่านั้น
ถ: ควรใช้ S256 หรือ plain? ตอบ: ใช้ S256 ในแทบทุกกรณี เพราะ challenge เดินทางไปกับ redirect URL ถ้าส่ง verifier แบบไม่ hash (plain) เท่ากับเปิดเผย secret บน front channel plain มีไว้สำหรับ client ที่คำนวณ SHA-256 ไม่ได้เท่านั้น
ถ: ทำไม verifier ต้องยาว 43-128 ตัวอักษร? ตอบ: RFC 7636 อนุพันธ์ขอบเขตนี้จาก entropy — 43 ตัวอักษรของ Base64URL encode ได้อย่างน้อย 256 bits ซึ่งเป็นค่าขั้นต่ำที่ RFC ถือว่าปลอดภัยจากการเดา ส่วน 128 ตัวอักษรทำให้รูป encoded ไม่เกิน 96 bytes สำหรับการเทียบฝั่ง server
ถ: tool ส่ง verifier ของผมไป server ไหม? ตอบ: ไม่ การ generate, hash และ validation ทำงานใน browser ของคุณล้วน ๆ ผ่าน Web Crypto API ไม่มี backend call และไม่มีการเก็บข้อมูล — คู่ values จะหายไปเมื่อปิด tab
ถ: ใช้ tool กับ code_verifier ที่มีอยู่แล้วได้ไหม? ตอบ: ได้ paste เข้าช่อง custom verifier ได้เลย tool จะ validate ตาม charset ของ RFC 7636 แล้วคำนวณ S256 challenge ให้ทันที