Basic Auth Generator: สร้าง Authorization Header อย่างปลอดภัยในเบราว์เซอร์
สร้าง HTTP Basic Auth Authorization header จาก username และ password — เลือก base64 แบบ UTF-8 หรือ Latin-1 พร้อม curl และ fetch snippet และตัวอย่าง .htpasswd ทำงานในเบราว์เซอร์ 100% รหัสผ่านไม่มีวันออกจากเครื่องคุณ
Table of Contents
Basic Auth Generator: สร้าง Authorization Header อย่างปลอดภัยในเบราว์เซอร์
Basic Auth อาจดูเป็นเทคโนโลยีเก่า แต่จริง ๆ แล้วยังใช้กันอยู่ทั่วไปจนน่าประหลาดใจ — ทั้งเว็บ staging ที่กั้นสิทธิ์การเข้าถึงไว้ก่อนเปิดตัว, เครื่องมือภายในองค์กร, หน้า admin panel, เราเตอร์และกล้อง IP ที่มีหน้าเว็บจัดการ ไปจนถึง webhook ของบริการภายนอกที่ยังคาดหวัง shared secret แบบง่าย ๆ ความเรียบง่ายนี่เองที่ทำให้มันอยู่รอดมาถึงวันนี้ และก็เป็นความเรียบง่ายเดียวกันที่ทำให้การสร้าง header ด้วยมือพลาดง่ายมาก — เข้ารหัสผิดก็โดนเซิร์ฟเวอร์ปฏิเสธทันที วางรหัสผ่านผิดที่ก็ไปจบลงใน shell history หรือถูก commit เข้า git ซะงั้น
เครื่องมือ Basic Auth Generator ฟรีของเราสร้าง header Authorization: Basic ... ให้โดยอัตโนมัติ เพียงกรอก username และ password เลือก encoding เป็น UTF-8 หรือ Latin-1 แล้วเครื่องมือจะสร้าง credential string แบบ base64 พร้อมทั้ง curl และ fetch snippet ที่คัดลอกไปใช้ได้ทันที รวมถึงตัวอย่างไฟล์ .htpasswd ทุกอย่างทำงานในเบราว์เซอร์ของคุณทั้งหมด — JavaScript บนเครื่องคุณเป็นคนเข้ารหัสเอง ไม่มีข้อมูลใดถูกส่ง บันทึก หรือเก็บไว้ที่ใดเลย
บทความนี้จะอธิบายว่า Basic Auth ส่งอะไรไปจริง ๆ ทำไมเรื่อง encoding จึงสำคัญกว่าที่นักพัฒนาส่วนใหญ่คิด, snippet แต่ละแบบต่างกันอย่างไร และโครงสร้างแบบนี้ยังเหมาะกับงานแบบไหนในปี 2026 — และแบบไหนที่ต้องใช้คู่กับ HTTPS และการจัดการ credential ที่ดีเสมอ
ทำไมต้องใช้ Basic Auth Generator?
คำสั่ง encode base64 มีให้ใช้เพียบ แต่เครื่องมือเฉพาะทางช่วยตัดจุดพลาดออกไปได้ นี่คือเหตุผลที่เครื่องมือนี้ควรอยู่ในกล่องเครื่องมือของคุณ:
- รหัสผ่านไม่เคยออกจากเบราว์เซอร์ กระบวนการทั้งหมด — การต่อ string, การเข้ารหัส, การสร้าง snippet — รันฝั่ง client ทั้งหมด ต่างจากเว็บ encode ทั่วไปที่ส่งข้อมูลที่คุณพิมพ์ขึ้นเซิร์ฟเวอร์ (และมักเก็บ log ไว้) เครื่องมือนี้ไม่มีการยิง request ไปเซิร์ฟเวอร์เลยสักครั้ง ซึ่งเป็นเรื่องสำคัญมากเมื่อ input คือ credential จริง
- จัดการ UTF-8 กับ Latin-1 อย่างถูกต้อง ประวัติของ Basic scheme ทำให้รหัสผ่านที่มีตัวอักษรไม่ใช่ ASCII กลายเป็นเรื่องคลุมเครือ เครื่องมือให้คุณเลือก encoding ได้ชัดเจน แทนที่จะสร้าง header ที่เงียบ ๆ ใช้ได้ในเบราว์เซอร์หนึ่งแต่พังในอีกเบราว์เซอร์หนึ่ง
- ไม่มีร่องรอยใน shell history หรือคลิปบอร์ด การพิมพ์ echo -n "user:pass" | base64 ลง terminal ทิ้งข้อความ plaintext ไว้ใน history เครื่องมือนี้ทำงานในหน้าเว็บโดยไม่บันทึกอะไรลงเครื่องเลย
- มี curl และ fetch snippet สำเร็จรูป คุณได้คำสั่ง curl -u ตรงตามที่ต้องใช้ และ fetch call ที่แนบ Authorization header ที่ถูกต้องมาให้เลย ไม่ต้องนั่งประกอบ syntax เอง
- มีตัวอย่าง .htpasswd ให้พร้อมกับ header รูปแบบ .htpasswd ของ Apache มักถูกเข้าใจผิดว่าเหมือนกับ base64 header เครื่องมือแสดงรูปแบบจัดเก็บแบบ bcrypt ที่ถูกต้อง เพื่อไม่ให้คุณนำ "hash" แบบถอดกลับได้ไป deploy โดยไม่รู้ตัว
- ใช้งานรวดเร็ว ไม่มีขั้นตอนยุ่งยาก ไม่ต้อง login ไม่มีโฆษณา ไม่มีขีดจำกัด เปิดหน้าเว็บ พิมพ์ ก็อปปี้ — ความเร็วแบบนี้สำคัญเวลาที่คุณต้องหมุนเวียน credential ของ staging หลายครั้งต่อสัปดาห์
ฟีเจอร์หลัก
Basic Auth Generator รวมสิ่งจำเป็นของ Basic scheme ไว้ในหน้าเดียวที่ทำงานฝั่ง client:
| ฟีเจอร์ | ทำอะไร | ทำไมจึงสำคัญ |
|---|---|---|
| สร้าง header | สร้าง Authorization: Basic base64 จาก username และ password ที่กรอก | ตัดความผิดพลาดจากการ encode ด้วยมือออกไป |
| เลือก encoding | UTF-8 หรือ Latin-1 สำหรับ credential ที่ไม่ใช่ ASCII | ให้ตรงกับสิ่งที่เซิร์ฟเวอร์และ client ฝั่งรับคาดหวังจริง |
| curl snippet | สร้างคำสั่ง curl -u user:pass หนึ่งบรรทัด | ทางเร็วสุดในการทดสอบ request จาก terminal |
| fetch snippet | สร้าง fetch call ที่แนบ Authorization header ที่คำนวณแล้ว | ก็อปปี้ลงสคริปต์เบราว์เซอร์หรือโค้ด Node ได้ทันที |
| ตัวอย่าง .htpasswd | แสดงบรรทัดรูปแบบ bcrypt ที่ Apache ต้องการ | ป้องกันการสับสนระหว่าง encoding ของ header กับการจัดเก็บรหัสผ่าน |
| ประมวลผลฝั่ง client | ทุกอย่างคำนวณในเบราว์เซอร์ของคุณ | ไม่มี credential ถูกส่งออกหรือถูกเก็บไว้ที่ใด |
มีรายละเอียดเล็ก ๆ อีกไม่กี่อย่างที่ช่วยให้ workflow สมบูรณ์ เครื่องมือตรวจว่า username ไม่มีอักขระ colon มาก่อน เพราะ scheme ไม่มีกลไก escape และ colon ตัวแรกจะเป็นตัวแบ่ง username เสมอ นอกจากนี้ยังรองรับกรณีพิเศษที่กรอกแค่ password โดย credential จะกลายเป็น :password ส่วนผลลัพธ์ถูกจัดรูปแบบให้กดคัดลอกได้ทีละส่วน ไม่ว่าจะเป็น header ดิบ, base64 ล้วน หรือ snippet แบบใดแบบหนึ่ง
วิธีใช้งาน
ทั้งกระบวนการใช้เวลาไม่ถึงหนึ่งนาที:
- เปิดเครื่องมือ เข้าไปที่ Basic Auth Generator ด้วยเบราว์เซอร์สมัยใหม่ตัวไหนก็ได้ ไม่ต้องสมัครบัญชี ไม่ต้องติดตั้งอะไร
- กรอก username และ password พิมพ์ทั้งสองค่าลงในช่องฟอร์ม จำไว้ว่า colon ตัวแรกจะแบ่งคู่ credential ดังนั้น username ต้องไม่มี colon
- เลือก encoding ปล่อยไว้เป็น UTF-8 สำหรับระบบสมัยใหม่แทบทั้งหมด เปลี่ยนเป็น Latin-1 เฉพาะเมื่อคุณรู้แน่ชัดว่าเซิร์ฟเวอร์หรือ client รุ่นเก่าฝั่งรับถอดรหัส Basic credential แบบนั้น (อ่านเพิ่มด้านล่าง)
- คัดลอกผลลัพธ์ที่ต้องการ หยิบ Authorization: Basic ... ดิบ, คำสั่ง curl, fetch snippet หรือบรรทัดตัวอย่าง .htpasswd แล้วแต่ขั้นตอนถัดไปของคุณคืออะไร
- ใช้งานแล้วลบทิ้ง ทดสอบ request, deploy config แล้วลบ credential ที่คัดลอกไว้ออกจากคลิปบอร์ด ถ้าเป็น credential จริงก็อย่าลืมหมุนเวียนตามรอบปกติของทีม
user:pass ในรูปแบบ Base64
ส่วนนี้คือหัวใจที่ควรเข้าใจ เพราะ Basic scheme ดูง่ายแต่แอบมีดักอยู่หลายจุด
ตัว scheme เองทำงานอย่างไร
RFC 7617 นิยาม Basic Auth ไว้เพียงบรรทัด header เดียว client นำ username มาต่อด้วย colon หนึ่งตัว ต่อด้วย password เข้ารหัส string นั้นด้วย base64 แล้วส่งไปเป็น credential ของ scheme ชื่อ Basic:
Authorization: Basic ZGV2b3BzLWFkbWluOlN0cjBuZyFQYXNz
ถอดรหัส ZGV2b3BzLWFkbWluOlN0cjBuZyFQYXNz ออกมาได้เป็น devops-admin:Str0ng!Pass — และนี่คือเรื่องราวด้านความปลอดภัยทั้งหมดของ header นี้ base64 เป็น encoding ไม่ใช่การเข้ารหัสลับ ใครก็ตามที่เห็นหรือดัก header ได้ จะกู้คืนรหัสผ่านกลับมาได้ทันที นั่นคือเหตุผลที่ Basic Auth จะป้องกันตัวเองได้ก็ต่อเมื่อใช้ผ่าน HTTPS เท่านั้น ซึ่งเราจะกลับมาพูดถึงอีกครั้งในหัวข้อ best practices
ทำไมการเลือก encoding จึงสำคัญ
สังเกตว่า scheme ไม่ได้พูดถึง character encoding ของ string ที่ถูกต่อกันเลย สำหรับ credential ที่เป็น ASCII ล้วน UTF-8 และ Latin-1 ให้ผล byte เหมือนกัน คำถามนี้จึงไม่เกิดขึ้น แต่พอรหัสผ่านมีอักขระอย่าง ä, é หรือ § ทั้งสอง encoding ก็แตกต่างกันทันที: UTF-8 เก็บ ä เป็นสอง byte (0xC3 0xA4) ขณะที่ Latin-1 ใช้ byte เดียว (0xE4) ผลลัพธ์ base64 ต่างกันตามไปด้วย และเซิร์ฟเวอร์จะถอดกลับเป็น encoding ที่ตัวเองสมมติไว้
ในทางปฏิบัติ ระบบสมัยใหม่ทั้งเบราว์เซอร์, curl และเซิร์ฟเวอร์ที่สร้างในทศวรรษที่ผ่านมา ถือว่า credential เป็น UTF-8 แต่ Apache รุ่นเก่าและอุปกรณ์ embedded รุ่นเก่ามักตีความ string เป็น Latin-1 (ISO-8859-1) ถ้า header ที่สร้างแล้ว "ใช้ได้ในเบราว์เซอร์แต่ใช้ไม่ได้ใน curl" หรือกลับกัน สาเหตุอันดับแรกคือ encoding ไม่ตรงกัน เครื่องมือทำให้การเลือกชัดเจน เพื่อให้คุณจับคู่กับฝั่งรับได้: UTF-8 สำหรับเป้าหมายสมัยใหม่, Latin-1 สำหรับอุปกรณ์เก่าที่เห็นได้ชัดว่าเพี้ยนกับตัวอักษรมีเครื่องหมายเสริม
snippet ที่ได้จากเครื่องมือ
เครื่องมือสร้าง snippet สองแบบที่แตกต่างกันอย่างละเอียดและเหมาะกับสไตล์การ debug ต่างกัน
curl snippet ใช้ flag -u ซึ่งจัดการเรื่องการต่อ string และการเข้ารหัสให้เอง:
curl -u devops-admin:Str0ng!Pass https://staging.example.com/
รูปแบบนี้อ่านง่ายและเห็น credential ชัด เหมาะกับการทดสอบครั้งเดียวกับบัญชี dummy ส่วน fetch snippet ฝัง header ที่คำนวณแล้วเอาไว้เลย ซึ่งเป็นสิ่งที่คุณต้องการเวลา debug แอปพลิเคชันที่ต้องส่ง header เอง:
fetch(url, { headers: { 'Authorization': 'Basic ZGV2b3BzLWFkbWluOlN0cjBuZyFQYXNz' } })
ถ้า request ผ่านด้วยรูปแบบ curl แต่ fetch call กลับคืน 401 ปัญหาอยู่ที่วิธีที่โค้ดฝั่ง client ประกอบ header — กลุ่ม bug ที่ fetch snippet ที่สร้างให้ทำให้เห็นได้ทันที
ตัวอย่างไฟล์ .htpasswd
จุดที่สับสนกันบ่อย: string base64 ใน Authorization header ไม่ใช่ password hash และห้ามใช้เป็น hash เด็ดขาด บรรทัดใน .htpasswd หน้าตาต่างกันคนละเรื่อง — มันเก็บ hash ที่คำนวณช้าและมี salt เฉพาะ โดยทั่วไปคือ bcrypt:
devops-admin:$2y$10$kX9qWzR4vN8pQ2mT5yL3bOuC7dGfJ1aHsXeVrK9wPzQnM2iB4cD6e
base64 header ถอดกลับได้โดยการออกแบบ ส่วนบรรทัด .htpasswd ไม่สามารถถอดกลับได้ ตัวอย่าง .htpasswd ในเครื่องมือแสดงรูปแบบ bcrypt ที่ถูกต้องเพื่อไม่ให้สองอย่างนี้ถูกมักรวมกัน ถ้าคุณต้องสร้างหรือตรวจสอบ hash เหล่านี้จริง ๆ เครื่องมือสร้าง hash บนเว็บไซต์นี้คือคู่หูที่ใช่ ส่วน htaccess generator ช่วยเรื่อง config ของ Apache ที่ล้อมรอบไว้
กรณีใช้งานจริง
ป้องกันสภาพแวดล้อม staging
กรณีคลาสสิกที่สุด deployment บน staging ไม่ควรเปิดให้สาธารณะ แต่การติดตั้ง SSO เต็มรูปแบบก็เกินจำเป็นก่อนเปิดตัว กำแพง Basic Auth — shared credential เดียวสำหรับทั้งทีม — ติดตั้งเสร็จในห้านาที และกัน visitor ทั่วไปกับ crawler ออกไปได้ สร้าง header, วางลง config ของ web server หรือ proxy แล้วหมุนเวียนรหัสผ่านทุกครั้งที่มีคนออกจากโปรเจกต์
ทดสอบ API อย่างรวดเร็ว
เมื่อคุณต้องยืนยันว่า auth middleware ของ endpoint ปฏิเสธ traffic ที่ไม่ผ่านการยืนยันตัวตนจริง ๆ ไม่มีอะไรเร็วกว่าการยิง curl หนึ่งคำสั่งพร้อม header ที่สร้างมาแล้ว snippet ที่ได้ช่วยให้คุณทดสอบทั้ง happy path และ 401 path ได้ในไม่กี่วินาที โดยไม่ต้องเขียน test harness ก่อน
เราเตอร์และอุปกรณ์ที่รองรับแค่ Basic Auth
เราเตอร์บ้าน, กล้อง IP, NAS และตัวควบคุม IoT หลายรุ่นมี Basic Auth เป็นตัวเลือกเดียวสำหรับ API อุปกรณ์เก่าจำนวนมากถอดรหัส credential แบบ Latin-1 ซึ่งเป็นจุดที่ปุ่มสลับ encoding เป็นประโยชน์ที่สุด: ถ้า header ที่มีอักขระเสริมถูกเว็บ UI ของอุปกรณ์ปฏิเสธ ให้สร้างใหม่โดยเลือก Latin-1
CI smoke tests
smoke test ประจำคืนที่เรียก URL บน staging ที่มีกำแพง Basic ต้องการ auth เพียงพอให้ผ่านประตู เก็บ credential ไว้เป็น secret variable ของ CI แล้วฉีดเข้าไปใน fetch snippet รูปแบบ header สำเร็จรูป ช่วยให้ test ง่ายโดยไม่รั่วไหลของรหัสผ่านลง log หรือ repository
Best Practices
Basic Auth ใช้ได้ในบริบทที่เหมาะสม แต่ต้องจัดการอย่างระมัดระวัง:
- ใช้ Basic Auth คู่กับ HTTPS เสมอ header นี้แทบเป็น plaintext บน HTTP ธรรมดา credential จะมองเห็นได้จากทุกจุดบนเส้นทาง ทั้ง proxy, ผู้ให้บริการ Wi-Fi และเครื่องดักแพ็กเก็ต อย่าออกหรือยอมรับ Basic Auth บนการเชื่อมต่อที่ไม่เข้ารหัสเด็ดขาด
- หมุนเวียน credential ของ staging ตามตาราง shared password มักมีสิทธิ์มากขึ้นเรื่อย ๆ ตามเวลา กำหนดรอบการหมุนเวียน — รายเดือนเป็นค่าเริ่มต้นที่สมเหตุสมผล — และหมุนทันทีเมื่อมีสมาชิกทีมออก
- ห้าม commit header ที่สร้างจากรหัสผ่านจริงลง repository ผลลัพธ์ถอดกลับได้ header, snippet และไฟล์ config ที่มี credential จริงควรอยู่ใน shell session หรือ secrets manager เท่านั้น การรัน PII Redactor ผ่านไฟล์ก่อน commit เป็นตาข่ายนิรภัยที่ถูกมาก
- เลือกใช้ credential แยกรายผู้ใช้ ถ้าเซิร์ฟเวอร์รองรับ ออก credential หนึ่งชุดต่อคนหรือต่อ pipeline แทนการใช้คู่เดียวร่วมกัน เพื่อให้เพิกถอนสิทธิ์รายคนได้
- ตั้ง rate limit และ lockout ให้ endpoint ที่ยืนยันตัวตน Basic Auth ไม่มีการป้องกัน brute force ในตัวบนเซิร์ฟเวอร์ส่วนใหญ่ เปิด fail2ban หรือ throttling ที่เทียบเท่ากับทุกอย่างที่เปิดให้เข้าถึงนอก localhost
- มองว่าเป็นทางชั่วคราว ไม่ใช่กลยุทธ์ สำหรับระบบที่อยู่ยาวหรือเปิดให้ผู้ใช้จริง ย้ายไป session-based auth หรือ OAuth 2.0 ที่จัดการ token อย่างถูกต้อง Basic Auth เก่งในงาน staging, การทดสอบ และการจัดการอุปกรณ์ — ไม่ใช่ชั้น identity ของ production
เริ่มสร้าง Header ของคุณเลย
เลิกคำนวณ base64 ด้วยมือใน terminal เถอะ เปิด Basic Auth Generator, กรอก credential, เลือก encoding ให้ตรงกับเซิร์ฟเวอร์ แล้วคัดลอก Authorization header, curl snippet, fetch snippet หรือตัวอย่าง .htpasswd ที่ถูกต้องได้ในไม่กี่วินาที — คำนวณทั้งหมดในเบราว์เซอร์ของคุณ ไม่มีอะไรถูกส่งไปที่ใดเลย
เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:
- OpenSSL Command Generator — สร้างคำสั่ง openssl สำหรับ key, certificate และการ encode ได้ถูกต้องโดยไม่ต้องจำ flag
- htaccess Generator — สร้าง snippet ไฟล์ .htaccess ของ Apache รวมถึงส่วนการยืนยันตัวตนที่ใช้ไฟล์ .htpasswd
- PII Redactor — ลบ email, token และข้อมูลอ่อนไหวออกจากข้อความและไฟล์ก่อนแชร์หรือ commit
ทีม Online Tools Forge สร้างเครื่องมือสำหรับนักพัฒนาที่เร็ว ฟรี และเคารพความเป็นส่วนตัว โดยทำงานทั้งหมดในเบราว์เซอร์ของคุณ ถ้าบทความนี้ช่วยประหยัดเวลา debug ได้ แชร์ต่อให้เพื่อนร่วมทีมที่ยัง pipe credential ผ่าน shell history อยู่ดูสักคน
คำถามที่พบบ่อย
ถ: Authorization header ของ Basic Auth เหมือนการเข้ารหัสรหัสผ่านหรือไม่?
ตอบ: ไม่ใช่ base64 เป็น encoding ที่ถอดกลับได้ ไม่ใช่การเข้ารหัสลับ ใครก็ตามที่เห็น header สามารถถอดกลับเป็น user:pass ได้ทันที header จะปลอดภัยก็ต่อเมื่อส่งผ่าน HTTPS เท่านั้น ซึ่งจะเข้ารหัส request ทั้งหมด — รวมถึง Authorization header — ระหว่างทาง
ถ: ควรเลือก Latin-1 แทน UTF-8 เมื่อไร?
ตอบ: เฉพาะเมื่อเซิร์ฟเวอร์หรืออุปกรณ์ฝั่งรับถอดรหัส Basic credential เป็น ISO-8859-1 ซึ่งพบได้บ่อยใน Apache configuration รุ่นเก่าและอุปกรณ์ embedded รุ่นเก่า สำหรับ credential ที่เป็น ASCII ล้วน สอง encoding ให้ผลเหมือนกัน คำเลือกจึงมีผลเฉพาะเมื่อรหัสผ่านมีตัวอักษรเสริมหรืออักขระพิเศษ
ถ: เครื่องมือนี้ส่ง username และ password ไปที่เซิร์ฟเวอร์หรือไม่?
ตอบ: ไม่ส่ง ทุกการเข้ารหัสและการสร้าง snippet เกิดขึ้นใน JavaScript ภายในแท็บเบราว์เซอร์ของคุณ ไม่มี network request ที่แบบข้อมูล input ของคุณไป ไม่มีการเก็บ log และไม่มีการบันทึกอะไรทั้งสิ้น — ปิดแท็บแล้ว credential ก็หายไป
ถ: นำ string base64 ที่ได้ไปใช้เป็นข้อมูลใน .htpasswd ได้ไหม?
ตอบ: ห้ามเด็ดขาด string base64 ใน header ถอดกลับได้ ใครก็ตามที่เข้าถึงไฟล์จะกู้คืนรหัสผ่านกลับมาได้ ไฟล์ .htpasswd ต้องใช้ hash แบบช้าที่มี salt เช่น bcrypt ใช้ตัวอย่าง .htpasswd ในเครื่องมือดูรูปแบบที่ถูกต้อง และสร้าง hash จริงด้วยเครื่องมือ hashing เฉพาะทาง
ถ: ทำไม username ถึงมี colon ไม่ได้?
ตอบ: Basic scheme ต่อ username, colon หนึ่งตัว และ password เข้าด้วยกัน แล้วเซิร์ฟเวอร์แบ่งด้วย colon ตัวแรก ไม่มีกลไก escape ดังนั้น colon ใน username จะทำให้ credential กำกวม ถ้าระบบ identity ของคุณใช้ colon ใน username ให้เลือก credential อื่นสำหรับ Basic Auth