Authentication คืออะไร? การล็อกอิน เซสชัน และ OAuth อธิบายแบบเข้าใจง่าย

Authentication คือวิธีที่แอปยืนยันว่าผู้ใช้เป็นใคร โดยทั่วไปจะตรวจสิ่งที่ผู้ใช้รู้ (รหัสผ่าน) สิ่งที่ผู้ใช้มี (รหัสที่ส่งไปยังโทรศัพท์หรืออีเมล) หรือตัวตนจากบริการที่เชื่อถือได้อีกแห่ง (เช่น "Sign in with Google") เมื่อผู้ใช้ผ่านการยืนยันแล้ว แอปจะจำผู้ใช้ไว้ด้วยเซสชันหรือโทเค็น เพื่อไม่ต้องล็อกอินใหม่ทุกหน้า การตัดสินว่าผู้ใช้ที่รู้จักแล้วทำอะไรได้บ้างเป็นอีกขั้นตอนหนึ่งเรียกว่า authorization

ทำไมเรื่องนี้สำคัญเมื่อสร้างแอปด้วย AI

การเพิ่มระบบล็อกอินเป็นหนึ่งในคำขอที่คนขอจากตัวสร้างแอปด้วย AI บ่อยที่สุด และเป็นสิ่งที่ทำผิดได้ง่ายอย่างแนบเนียน หน้าล็อกอินนั้นสร้างง่าย ส่วนที่ยากคือทุกอย่างที่อยู่รอบๆ:

รหัสผ่านถูกเก็บอย่างปลอดภัยหรือไม่
ทุกหน้าส่วนตัวและทุก API endpoint ตรวจจริงหรือไม่ว่าใครเป็นผู้ขอ
ลูกค้าที่ล็อกอินอยู่สามารถเห็นข้อมูลของลูกค้าคนอื่นได้ไหม โดยเปลี่ยนตัวเลขในURL
เกิดอะไรขึ้นเมื่อมีคนลืมรหัสผ่าน

แอปอาจดูปลอดภัยสมบูรณ์แต่ล้มเหลวในทุกข้อเหล่านั้นได้ การเข้าใจชิ้นส่วนที่ทำงานร่วมกันช่วยให้คุณถามคำถามที่ถูกต้องและทดสอบสิ่งที่ถูกต้อง

ตัวอย่างเปรียบเทียบในชีวิตประจำวัน

ลองนึกภาพการเช็คอินโรงแรม

ที่เคาน์เตอร์หน้า คุณแสดงบัตรประชาชน นั่นคือ authentication: การพิสูจน์ว่าคุณเป็นใคร จากนั้นพนักงานจะให้บัตรคีย์การ์ดแก่คุณ บัตรนั้นคือ เซสชัน ตลอดการพักของคุณ คุณไม่ต้องแสดงบัตรประชาชนอีก เพียงแตะบัตร

บัตรนั้นเปิดห้องของคุณ ฟิตเนส และลิฟต์ไปยังชั้นของคุณ แต่ไม่เปิดห้องของแขกคนอื่นหรือห้องทำงานของพนักงาน นั่นคือ authorization: สิ่งที่ตัวตนของคุณได้รับอนุญาตให้เข้าถึง ถ้าคุณทำบัตรหาย โรงแรมสามารถปิดการใช้งานที่เคาน์เตอร์ได้ (การเพิกถอนเซสชัน) และเมื่อคุณเช็คเอาต์ บัตรก็หยุดใช้งาน (การออกจากระบบหรือหมดอายุ)

"Sign in with Google" เหมือนโรงแรมที่รับจดหมายจากพันธมิตรที่เชื่อถือได้ซึ่งระบุว่า "นี่คือผู้เข้าพัก" แทนที่จะตรวจบัตรประชาชนเอง

วิธีล็อกอินหลักๆ

วิธี	ทำงานอย่างไร	ข้อดี	ข้อเสีย
อีเมล + รหัสผ่าน	ผู้ใช้ตั้งรหัสผ่าน แอปเก็บแฮชของมัน	คุ้นเคย ไม่ต้องพึ่งบริการภายนอก	ต้องเก็บแฮชอย่างปลอดภัยและจัดการการรีเซ็ต
ลิงก์ล็อกอิน / รหัสครั้งเดียว	แอปส่งลิงก์หรือรหัสทางอีเมลเพื่อให้ผู้ใช้ล็อกอิน	ไม่มีรหัสผ่านให้รั่วไหลหรือลืม	ขึ้นกับการส่งอีเมล และล็อกอินช้ากว่า
การล็อกอินผ่านโซเชียล (OAuth / OpenID Connect)	ผู้ใช้ล็อกอินด้วย Google, Apple, GitHub ฯลฯ	รวดเร็วสำหรับผู้ใช้ คุณไม่ต้องเก็บรหัสผ่าน	ต้องตั้งค่ากับผู้ให้บริการแต่ละราย และผู้ใช้ที่ไม่มีบัญชีเหล่านั้น
ผู้ให้บริการยืนยันตัวตนแบบโฮสต์	บริการอย่าง Clerk, Auth0 หรือ Supabase Auth จัดการการสมัคร ล็อกอิน และการรีเซ็ต	คุณทำงานด้านความปลอดภัยน้อยลง	มีค่าใช้จ่ายรายเดือนเมื่อขยาย และเป็น dependency อีกตัว
Multi-factor (MFA / 2FA)	การยืนยันขั้นที่สองหลังขั้นแรก เช่น รหัสจากแอป authenticator	เจาะเข้ายากกว่ามาก	ใช้งานยุ่งยากขึ้นเล็กน้อย

วิธีเก็บรหัสผ่านที่ถูกต้อง

แอปที่ปลอดภัยไม่เคยเก็บรหัสผ่านจริงของคุณ แต่เก็บ แฮช ซึ่งเป็นผลลัพธ์จากฟังก์ชันทางเดียวที่แปลงรหัสผ่านให้เป็นสตริงคงที่ เมื่อคุณล็อกอิน แอปจะแฮชสิ่งที่คุณพิมพ์แล้วเปรียบเทียบกับแฮชที่เก็บไว้

มีสองรายละเอียดที่ทำให้วิธีนี้ปลอดภัย:

Salt คือค่าสุ่มที่เพิ่มเข้าไปในรหัสผ่านแต่ละตัวก่อนแฮช ทำให้คนสองคนที่ใช้รหัสผ่านเดียวกันได้แฮชต่างกัน และตารางค้นหาที่คำนวณไว้ล่วงหน้าใช้ไม่ได้
อัลกอริทึมช้าที่ออกแบบมาสำหรับรหัสผ่าน เช่น Argon2, bcrypt หรือ scrypt แฮชทั่วไปอย่าง MD5 หรือ SHA-256 เร็วเกินไปเมื่อใช้เดี่ยวๆ ผู้โจมตีสามารถลองเดาได้หลายพันล้านครั้ง

การแฮชไม่เหมือนการเข้ารหัส ข้อมูลที่เข้ารหัสสามารถถอดรหัสได้ด้วยคีย์ ส่วนแฮชรหัสผ่านถูกออกแบบให้ย้อนกลับไม่ได้เลย

เซสชันกับโทเค็น

หลังล็อกอิน แอปต้องจำได้ว่าเป็นคุณในทุกคำขอ มีสองแนวทางที่พบบ่อย

	เซสชัน (คุกกี้)	โทเค็น (เช่น JWT)
สิ่งที่เบราว์เซอร์ถือ	ID เซสชันแบบสุ่มในคุกกี้	โทเค็นที่ลงลายเซ็นซึ่งมีข้อมูลผู้ใช้และวันหมดอายุ
สถานะการล็อกอินอยู่ที่ไหน	บนเซิร์ฟเวอร์ ในฐานข้อมูลหรือที่เก็บข้อมูล	อยู่ในตัวโทเค็นเอง
ออกจากระบบทุกที่พร้อมกัน	ทำได้ง่าย: ลบเซสชันบนเซิร์ฟเวอร์	ยากกว่า: โทเค็นยังใช้ได้จนหมดอายุ เว้นแต่คุณจะมีรายการบล็อก
การใช้งานทั่วไป	เว็บแอปแบบดั้งเดิม	API แอปมือถือ บริการที่คุยกันเอง

สำหรับคุกกี้ มีการตั้งค่าสามอย่างที่สำคัญ: HttpOnly (JavaScript บนหน้าไม่สามารถอ่านคุกกี้ได้) Secure (ส่งเฉพาะผ่าน HTTPS) และ SameSite (จำกัดการส่งคุกกี้ในคำขอจากเว็บไซต์อื่น) การเก็บโทเค็นไว้ใน localStorage ของเบราว์เซอร์เป็นเรื่องที่พบบ่อย แต่ทำให้สคริปต์ใดๆ ที่ทำงานบนหน้าเข้าถึงโทเค็นได้

OAuth 2.0 เป็นมาตรฐานสำหรับ การมอบสิทธิ์ (delegated authorization) ซึ่งให้แอปได้สิทธิ์เข้าถึงบัญชีของคุณในบริการอื่นอย่างจำกัด เช่น อ่าน Google Calendar ของคุณ โดยไม่เคยเห็นรหัสผ่าน Google ของคุณ คุณจะถูกส่งไปยัง Google อนุมัติสิทธิ์เฉพาะ (เรียกว่า scopes) และ Google มอบโทเค็นให้แอปที่ครอบคลุมเพียงสิทธิ์เหล่านั้น

OAuth โดยตัวมันเองถูกออกแบบมาเพื่อให้สิทธิ์การเข้าถึง ไม่ใช่เพื่อบอกว่าคุณเป็นใคร OpenID Connect (OIDC) เป็นชั้นที่สร้างบน OAuth 2.0 เพื่อเพิ่มการระบุตัวตน ซึ่งเป็นสิ่งที่ "Sign in with Google" หรือ "Sign in with Apple" ใช้ ในการตั้งค่า คุณลงทะเบียนแอปกับผู้ให้บริการและได้ client ID กับ client secret โดย secret ต้องอยู่บนเซิร์ฟเวอร์ของคุณ

ตัวอย่างการทำงาน: ล็อกอินสำหรับพอร์ทัลลูกค้า

สมมติคุณกำลังสร้างพอร์ทัลที่ลูกค้าของเอเจนซี่ออกแบบจะเห็นโปรเจกต์และใบแจ้งหนี้ของตัวเอง

Authentication: ลูกค้าล็อกอินด้วยอีเมลและลิงก์ล็อกอิน จึงไม่มีรหัสผ่านให้จัดการ เจ้าหน้าที่ของเอเจนซี่ล็อกอินด้วยบัญชี Google Workspace
บทบาท: ผู้ใช้แต่ละคนมีบทบาท คือ client หรือ staff
กฎการเข้าถึง:

การกระทำ	ลูกค้า	เจ้าหน้าที่
ดูโปรเจกต์ของบริษัทตัวเอง	ได้	ได้
ดูโปรเจกต์ของบริษัทอื่น	ไม่ได้	ได้
อัปโหลดไฟล์เข้าโปรเจกต์	เฉพาะโปรเจกต์ของตัวเอง	ได้
ทำเครื่องหมายใบแจ้งหนี้ว่าจ่ายแล้ว	ไม่ได้	ได้

บังคับใช้ที่ไหน: บนเซิร์ฟเวอร์ สำหรับทุกคำขอ เซิร์ฟเวอร์ค้นหาผู้ใช้ที่ล็อกอินอยู่ แล้วส่งคืนเฉพาะโปรเจกต์ที่ project.company_id ตรงกับบริษัทของผู้ใช้ การซ่อนปุ่ม "Mark paid" ไม่เพียงพอ ตัว endpoint เองต้องปฏิเสธ

คำศัพท์ที่ควรรู้

คำศัพท์	ความหมาย
Authentication (AuthN)	การยืนยันว่าใครคือใคร
Authorization (AuthZ)	การตัดสินว่าพวกเขาทำอะไรได้
Session	การที่แอปจำได้ว่าคุณล็อกอินอยู่ระหว่างคำขอต่างๆ
Cookie	ข้อมูลเล็กๆ ที่เบราว์เซอร์ส่งกลับไปยังเว็บไซต์ในทุกคำขอ
JWT	JSON Web Token: โทเค็นที่ลงลายเซ็นและกะทัดรัด บรรจุข้อมูล เช่น ID ผู้ใช้และวันหมดอายุ
Role / permission	ป้ายกำกับ เช่น `admin` หรือ `member` ที่กำหนดการเข้าถึง
MFA / 2FA	การต้องการหลักฐานที่สอง เช่น รหัสจากแอป authenticator
SSO	Single sign-on: ล็อกอินครั้งเดียว (มักเป็นบัญชีบริษัท) สำหรับหลายแอป
401 กับ 403	"คุณเป็นใคร?" (ยังไม่ได้ยืนยันตัวตน) กับ "คุณทำแบบนั้นไม่ได้" (ไม่ได้รับอนุญาต)

ความผิดพลาดและความเข้าใจผิดที่พบบ่อย

ตรวจสิทธิ์เฉพาะในหน้า ถ้าเบราว์เซอร์ซ่อนปุ่มแต่ API ไม่ตรวจ ใครก็เรียก API โดยตรงได้
เชื่อ ID จาก URL /invoices/1042 ต้องตรวจว่าใบแจ้งหนี้ 1042 เป็นของผู้ใช้ที่ล็อกอินอยู่
เขียนการเข้ารหัสเอง ใช้ไลบรารีที่เป็นที่รู้จักหรือผู้ให้บริการ อย่าให้ AI คิดวิธีแฮชขึ้นมาเอง
การรีเซ็ตรหัสผ่านที่อ่อนแอ ลิงก์รีเซ็ตควรใช้ได้ครั้งเดียว หมดอายุเร็ว และไม่เปิดเผยว่าอีเมลนั้นมีบัญชีหรือไม่
สับสนระหว่างการล็อกอินของแอปกับของตัวสร้างแอป ผู้ใช้แอปของคุณแยกจากบัญชีของคุณในเครื่องมือที่ใช้สร้างแอป
ไม่จำกัดจำนวนการล็อกอิน หากไม่มีการจำกัด ผู้โจมตีสามารถลองรหัสผ่านได้ไม่สิ้นสุด

สิ่งที่ควรขอจากตัวสร้างแอปด้วย AI ของคุณ

"เพิ่มการสมัครและล็อกอินโดยใช้ [ไลบรารีหรือผู้ให้บริการที่เป็นที่รู้จัก] อย่าเขียนการแฮชรหัสผ่านเอง"
"เก็บรหัสผ่านที่แฮชด้วย bcrypt หรือ Argon2"
"ใช้คุกกี้ HttpOnly และ Secure สำหรับเซสชัน"
"เพิ่มบทบาท: admin และ member แสดงทุก endpoint และบอกว่าบทบาทใดเรียกได้บ้าง"
"บังคับบนเซิร์ฟเวอร์ว่าผู้ใช้อ่านและแก้ไขได้เฉพาะเรกคอร์ดของตัวเอง แล้วแสดงให้ฉันเห็นว่าตรวจอย่างไร"
"เพิ่มการรีเซ็ตรหัสผ่านด้วยลิงก์ใช้ครั้งเดียวที่หมดอายุภายในหนึ่งชั่วโมง"
"จำกัดอัตราการพยายามล็อกอิน"

จากนั้นทดสอบเองด้วย: สร้างบัญชีสองบัญชี แล้วลองเข้าถึงข้อมูลของบัญชีหนึ่งขณะล็อกอินด้วยอีกบัญชี คู่มือการเพิ่มการล็อกอินให้แอป และรายการตรวจความปลอดภัยสำหรับแอปที่สร้างด้วย AI จะช่วยให้คุณลึกขึ้น

Authentication ใน Mythex

Mythex ไม่มีผลิตภัณฑ์ยืนยันตัวตนสำเร็จรูปสำหรับผู้ใช้แอปของคุณ คุณเลือกแนวทาง ได้แก่ อีเมลกับรหัสผ่านที่เก็บในฐานข้อมูลของโปรเจกต์ หรือ SDK ของผู้ให้บริการแบบโฮสต์ แล้วขอให้เอเจนต์เพิ่มให้ คีย์ของผู้ให้บริการใส่ในความลับของโปรเจกต์ ไม่ใส่ในแชต และนี่แยกจากวิธีที่คุณล็อกอินเข้า Mythex เอง สูตรการเพิ่มการล็อกอินให้แอป ในเอกสารมี starter prompt ที่คุณนำไปปรับได้ และAPI คืออะไร อธิบายว่าการตรวจฝั่งเซิร์ฟเวอร์เหล่านี้อยู่ที่ไหน

คำถาม

ความแตกต่างระหว่าง authentication กับ authorization คืออะไร?

Authentication ตรวจว่าคุณเป็นใคร เช่น การตรวจรหัสผ่านของคุณ ส่วน Authorization ตัดสินว่าคุณทำอะไรได้บ้างเมื่อรู้ตัวตนแล้ว เช่น คุณเข้าหน้าผู้ดูแลระบบได้หรือไม่ หรือแก้ไขการจองของคนอื่นได้หรือไม่ แอปต้องมีทั้งสองอย่าง

OAuth คืออะไร?

OAuth 2.0 เป็นมาตรฐานที่ให้แอปได้สิทธิ์เข้าถึงบัญชีของคุณในบริการอื่นอย่างจำกัด โดยไม่ต้องเห็นรหัสผ่านของคุณ "Sign in with Google" ใช้ OpenID Connect ซึ่งเป็นชั้นระบุตัวตนที่สร้างบน OAuth 2.0 ทำให้แอปรู้ว่าคุณเป็นใครจาก Google

แอปของฉันควรเก็บรหัสผ่านไหม?

ไม่ควรเก็บในรูปแบบที่อ่านได้เด็ดขาด หากใช้การล็อกอินด้วยอีเมลและรหัสผ่าน ต้องเก็บรหัสผ่านเป็นแฮชที่มี salt โดยใช้อัลกอริทึมช้าที่ออกแบบมาสำหรับรหัสผ่าน เช่น Argon2 หรือ bcrypt แอปหลายตัวหลีกเลี่ยงปัญหานี้โดยใช้ผู้ให้บริการยืนยันตัวตนแบบโฮสต์ การล็อกอินผ่านโซเชียล หรือลิงก์ล็อกอินทางอีเมล

ควรใช้เซสชันหรือโทเค็นดี?

ใช้ได้ทั้งคู่ เซสชันเก็บสถานะการล็อกอินไว้ที่เซิร์ฟเวอร์และให้เบราว์เซอร์ถือ ID แบบสุ่มในคุกกี้ ซึ่งเพิกถอนได้ง่าย ส่วนโทเค็นอย่าง JWT บรรจุข้อมูลที่ลงลายเซ็นไว้ในตัวเอง เหมาะกับ API และแอปมือถือ แต่ยกเลิกก่อนหมดอายุได้ยากกว่า สำหรับเว็บแอปทั่วไป การใช้เซสชันแบบคุกกี้เป็นค่าเริ่มต้นที่เหมาะสม