Authentication + HTTPS ปลอดภัยยังไง

บทก่อนเราสร้าง API ได้แล้ว แต่ถ้าใครยิง DELETE /orders/123 ได้ทุกคน order ของลูกค้าก็จะโดนลบทั้งร้าน และถ้าข้อมูลวิ่งผ่าน internet โดยไม่ป้องกัน คนกลางก็แอบเห็น password และเลขบัตรเครดิตได้

บทนี้เจาะ 2 เรื่องใหญ่ที่ทำให้ HTTP ใช้งานจริงได้อย่างปลอดภัย

1. Authentication server รู้ได้ยังไงว่า request นี้มาจากใคร
2. HTTPS ทำให้เนื้อหาระหว่างทางถูกเข้ารหัส คนกลางอ่านไม่ออก

ส่วนที่ 1: Authentication

ปัญหา: HTTP ไม่มีความจำ

จำจากบท 1 ได้ไหม HTTP stateless ทุก request server ถือว่าเจอคนนี้ครั้งแรก ถ้าไม่มีอะไรช่วย server แยกไม่ออกว่า request นี้คือคนที่เพิ่ง login เมื่อสักครู่หรือไม่

ทางออกคือ client ต้อง พก “บัตรประจำตัว” ไปด้วยทุก requestบัตรนี้คืออะไร และใส่ไว้ไหน เป็นที่มาของหลายวิธีในการทำ authentication

Mental model: wristband งานคอนเสิร์ต

เข้าคอนเสิร์ตแสดงบัตรครั้งเดียวตอนเข้า จากนั้นได้ wristband กำไลยางเปลี่ยนสี จะกลับเข้ามาเมื่อไหร่ก็โชว์กำไลพอ ไม่ต้องยื่นบัตรประชาชนทุกครั้ง

• การโชว์บัตรประชาชน = login
• การรับ wristband = รับ token/cookie จาก server
• การโชว์ wristband เวลาเข้าซ้ำ = ส่ง token ใน header ทุก request
• Wristband หาย/หมดวัน = token หมดอายุ ต้อง login ใหม่

4 วิธีพกบัตรประจำตัว

1. HTTP Basic Auth

• ส่ง username:password (encode ด้วย base64) ไปใน header ทุก request
• Authorization: Basic dXNlcjpwYXNz
• ข้อดี: ง่ายสุด
• ข้อเสีย: ส่ง password ทุก request ถ้าไม่ใช้ HTTPS จะอันตรายมาก ปัจจุบันใช้น้อยแล้ว

2. Session + Cookie (แบบเว็บไซต์ทั่วไป)

1. User login ด้วย username/password (ส่งครั้งเดียว)
2. Server ตรวจถูก → สร้าง session ID เก็บใน database
3. Server ตอบ Set-Cookie: session=abc123 browser เก็บ cookie ไว้
4. Request ต่อๆ ไป browser ส่ง cookie อัตโนมัติserver อ่าน session ID → ค้น database → รู้ว่าใคร
5. Logout: ลบ cookie + ลบ session ใน DB

ข้อดี: ง่าย ปลอดภัย (password ส่งครั้งเดียว) browser จัดการ cookie ให้
ข้อเสีย: server ต้องเก็บ session ทำให้ scale ยากขึ้น (ทุก server ต้องเข้าถึง session store)

3. Bearer Token

1. User login → server ให้ token (ข้อความสตริงยาวๆ)
2. Client ส่ง header Authorization: Bearer eyJhbGc... ทุก request
3. Server ตรวจ token → รู้ว่าใคร

ข้อดี: ไม่ต้องใช้ cookie เหมาะกับ mobile app + third-party API
ข้อเสีย: client ต้องจัดการ token เอง (เก็บใน storage, แนบทุก request)

4. JWT (JSON Web Token)

• Token รูปแบบพิเศษ self-contained มีข้อมูลใน token เลย (user ID, role, วันหมดอายุ)
• Server ตรวจ signature → มั่นใจว่า token นี้ออกโดย server จริงๆ ไม่ถูกแก้
• ไม่ต้องเช็ค database → scale ง่าย
• มี 3 ส่วนคั่นด้วย . เช่น eyJhbGc.eyJ1c2Vy.XsZJgI
header.payload.signature

Authentication vs Authorization

2 คำที่เสียงคล้ายแต่ความหมายต่างกัน

• Authentication (ย่อว่า AuthN) “คุณคือใคร” → ยืนยันตัวตน (login, token) → เกี่ยวกับ status 401
• Authorization (ย่อว่า AuthZ) “คุณทำอะไรได้บ้าง” → ตรวจสิทธิ์ (admin? เจ้าของ order?) → เกี่ยวกับ status 403

เช่น ลูกค้าคนหนึ่ง login แล้ว (AuthN ผ่าน) แต่จะลบ order ของคนอื่น (AuthZ ไม่ผ่าน) → 403

ดู flow login ของแอพกาแฟ

POST /login
{ "email": "[email protected]", "password": "••••••" }

ส่วนที่ 2: HTTPS

ปัญหา: HTTP เป็น plain text

HTTP message ที่เรียนในบท 3 เป็น text ธรรมดา ใครก็อ่านได้ ถ้าคุณ login ผ่าน WiFi ร้านกาแฟด้วย HTTP คนที่นั่งข้างๆ เปิด tool ดักจับ packet ก็เห็น password, เลขบัตรเครดิต, cookie ได้ทั้งหมด

การแอบดักฟัง/แก้ข้อมูลกลางทางเรียกว่า MITM attack (Man In The Middle) HTTPS มาแก้ปัญหานี้

HTTPS คือ HTTP + TLS

• HTTPS = HTTP ห่อด้วย TLS
• TLS (Transport Layer Security) คือ protocol เข้ารหัส ชื่อเดิมคือ SSL
• HTTP message ยังเหมือนเดิมทุกประการ แค่ถูก เข้ารหัส ก่อนส่ง
• คนกลางเห็นแค่ขยะ อ่านไม่ได้ แก้ไม่ได้

สิ่งที่ TLS ให้

1. Encryption เข้ารหัสเนื้อหา ใครดักฟังก็เห็นเป็นสุ่มไร้ความหมาย
2. Authentication (ของ server)ยืนยันว่า coffeeshop.com ที่คุณคุยด้วยคือของจริง ไม่ใช่ server ปลอมที่แกล้งชื่อ
3. Integrity กันการแก้ไขกลางทาง ถ้าคนกลางพยายามแก้ client จะรู้

POST /login HTTP/1.1
Host: coffeeshop.com

{ "email": "[email protected]", "password": "s3cr3t!" }

Certificate คืออะไร

• TLS certificate คือ “บัตรประจำตัว” ที่ server แสดงให้ client เพื่อพิสูจน์ตัวตน
• ออกโดย Certificate Authority (CA) องค์กรที่ browser ทั่วโลกเชื่อถือ เช่น Let's Encrypt, DigiCert, Sectigo
• Browser มี trust list ของ CA ติดมาในตัว ถ้า certificate ของ server ลงชื่อโดย CA ในรายการ = เชื่อได้
• Certificate มีวันหมดอายุ (ส่วนใหญ่ 90 วัน - 1 ปี) ต้อง renew

TLS handshake แบบสั้นๆ

1. Client ส่ง “สวัสดี นี่รายการ cipher ที่ฉันรองรับ”
2. Server ตอบ “นี่ certificate ของฉัน + cipher ที่เลือกใช้”
3. Client ตรวจ certificate ว่าลงชื่อโดย CA ที่เชื่อถือและยังไม่หมดอายุ
4. ทั้งสองฝั่งแลกเปลี่ยน key ผ่านคณิตศาสตร์ (ใช้กุญแจสาธารณะ)
5. หลังจากนั้นใช้ key ที่ได้เข้ารหัสเนื้อหาทุก message

ขั้นตอนนี้เกิดในเสี้ยววินาที ผู้ใช้ไม่รู้ตัว รู้แค่ว่าเห็น 🔒 ที่ address bar

คำศัพท์จากบทนี้

• Authentication (AuthN) ยืนยันว่าเป็นใคร
• Authorization (AuthZ) ตรวจว่ามีสิทธิ์ทำอะไร
• Session / Cookie วิธีให้ server จำ user ในเว็บ
• Token / Bearer บัตรที่ client พกใน header
• JWT token ที่มีข้อมูล self-contained ภายใน
• OAuth protocol ยืม login จากผู้ให้บริการอื่น
• TLS / SSL protocol เข้ารหัสเส้นทาง
• Certificate บัตรประจำตัวของ server
• CA (Certificate Authority) องค์กรที่ออก certificate
• MITM การดักฟัง/แก้ระหว่างทาง

สรุป

• HTTP stateless ทำให้ต้องส่ง “บัตร” ทุก request
• วิธีที่ใช้บ่อย: Cookie session (เว็บ), Bearer token / JWT (API), OAuth (login with X)
• AuthN = คุณเป็นใคร (401), AuthZ = ทำอะไรได้ (403)
• HTTPS = HTTP + TLS เข้ารหัสเนื้อหา + ยืนยัน server + กันการแก้กลางทาง
• 🔒 แปลว่าเส้นทางปลอดภัย ไม่ใช่ว่าเว็บน่าเชื่อถือ ตรวจ domain ด้วย
• เว็บยุคนี้ทุกที่ควรใช้ HTTPS เท่านั้น (ฟรีได้จาก Let's Encrypt)

เราเรียน 9 บทครบทุก concept ของ HTTP + API แล้ว บทสุดท้ายจะเป็นบทปฏิบัติ ลองเปิด DevTools ในเบราว์เซอร์ที่ใช้ทุกวัน ดู request จริงของ Facebook/YouTube/Google ที่ส่งเบื้องหลัง และลอง ยิง request ด้วยตัวเอง ผ่าน widget playground ในเว็บเรา ไม่ต้องเขียน code เห็นทุกอย่างที่เรียนมาเป็นของจริง