Implicit Grant Type ใน OAuth 2.0

Implicit Grant Type หรือที่รู้จักกันในชื่อวิธี "token" ออกแบบมาเป็นหลักสำหรับแอปพลิเคชันฝั่งไคลเอนต์ที่ไคลเอนต์ไม่สามารถจัดเก็บ client secret ได้อย่างปลอดภัย แอปพลิเคชันเหล่านี้รวมถึง single-page apps (SPAs) หรือแอปพลิเคชันที่ทำงานบนเบราว์เซอร์ แทนที่จะรับ authorization code ที่ต้องแลกเปลี่ยนเป็น access token แอปพลิเคชันจะได้รับ access token โดยตรง

Implicit Grant Type ทำงานอย่างไร?

1. การเปลี่ยนเส้นทาง (Redirection):

• แอปพลิเคชันไคลเอนต์เปลี่ยนเส้นทางผู้ใช้ไปยัง authorization endpoint ของเซิร์ฟเวอร์ OAuth 2.0 การเปลี่ยนเส้นทางนี้โดยปกติจะรวม query parameters เช่น client_id, response_type (ตั้งค่าเป็น "token" สำหรับ Implicit Grant), redirect_uri (ที่เซิร์ฟเวอร์จะเปลี่ยนเส้นทางหลังจากอนุญาต/ปฏิเสธการเข้าถึง) และ scope (บ่งบอกระดับการเข้าถึงที่ร้องขอ)

2. การยืนยันตัวตนผู้ใช้ (User Authentication):

• ผู้ใช้เข้าสู่ระบบเซิร์ฟเวอร์ authorization (หากยังไม่ได้เข้าสู่ระบบ) และตรวจสอบคำขอเข้าถึงจากแอปพลิเคชันไคลเอนต์

3. การออก Access Token:

• หากผู้ใช้อนุญาตการเข้าถึง เซิร์ฟเวอร์ authorization จะเปลี่ยนเส้นทางกลับไปยังแอปพลิเคชันไคลเอนต์ผ่าน redirect_uri ที่ให้ไว้ URI การเปลี่ยนเส้นทางจะรวม access token (และวันหมดอายุ) โดยตรงในส่วน fragment ของ URL

4. เข้าถึงทรัพยากรที่ป้องกัน:

• แอปพลิเคชันไคลเอนต์ดึง access token จาก URL fragment และจัดเก็บ (เช่น ใน local storage หรือ session) จากนั้นใช้ token นี้เพื่อส่งคำขอไปยัง resource server (API) ในนามของผู้ใช้

วิธีกำหนดค่า Implicit Grant Type?

1. ลงทะเบียนแอปพลิเคชันของคุณ:

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

2. ตั้งค่า Redirect URI:

• ระบุ redirect_uri ระหว่างการลงทะเบียน เซิร์ฟเวอร์ authorization จะเปลี่ยนเส้นทางผู้ใช้ไปยัง URI นี้หลังจากตัดสินใจอนุญาตหรือปฏิเสธการเข้าถึง ตรวจสอบให้แน่ใจว่า URI นี้ปลอดภัย (โดยทั่วไปใช้ HTTPS) และสามารถจัดการการดึง token จาก URL fragment ได้

3. เริ่ม OAuth Flow:

• เปลี่ยนเส้นทางผู้ใช้ไปยัง authorization endpoint ของเซิร์ฟเวอร์ authorization พร้อมพารามิเตอร์ที่จำเป็น ใช้ libraries หรือ SDKs ที่เหมาะกับภาษาหรือ framework ของแอปพลิเคชัน

4. ดึงและจัดเก็บ Token:

• เมื่อถูกเปลี่ยนเส้นทางกลับ ให้ดึง access token จาก URL fragment จัดเก็บ token อย่างปลอดภัย โดยพิจารณาตัวเลือกการจัดเก็บฝั่งไคลเอนต์เช่น Web Storage (localStorage หรือ sessionStorage) หรือ cookies ตรวจสอบให้แน่ใจว่าได้รับการป้องกันจากการโจมตี cross-site scripting (XSS)

5. ใช้ Token:

• แนบ access token กับ API requests ที่ส่งไปยัง resource server

6. จัดการ Token หมดอายุ:

• เนื่องจาก Implicit Grant โดยปกติไม่ให้ refresh tokens เมื่อ access token หมดอายุ คุณอาจต้องเริ่ม OAuth flow ใหม่เพื่อขอ token ใหม่

สิ่งที่ควรพิจารณา:

• ความปลอดภัย: Implicit Grant Type ถือว่าปลอดภัยน้อยกว่า Authorization Code Grant Type โดยเฉพาะเพราะ access token ถูกเปิดเผยใน URL ซึ่งอาจเป็นความเสี่ยงในสภาพแวดล้อมที่ URLs สามารถถูกบันทึกหรือเข้าถึงโดยบุคคลที่สาม

• ไม่มี Refresh Token: โดยทั่วไป Implicit Grant ไม่ให้ refresh tokens ดังนั้นเมื่อ access token หมดอายุ อาจต้องทำ flow ทั้งหมดซ้ำ

• การเลิกใช้: เนื่องจากปัญหาความปลอดภัยโดยธรรมชาติ เอกสาร OAuth 2.0 Security Best Current Practice แนะนำให้หลีกเลี่ยง Implicit Grant และใช้ Authorization Code พร้อม PKCE (Proof Key for Code Exchange) แทนสำหรับ public clients เช่น SPAs

สรุป:

แม้ Implicit Grant Type จะเสนอ flow ที่ง่ายกว่าสำหรับแอปฝั่งไคลเอนต์ แต่ปัญหาความปลอดภัยทำให้มีคำแนะนำไม่ให้ใช้ในแอปพลิเคชันสมัยใหม่ หากคุณกำลังสร้างแอปพลิเคชันใหม่ โดยเฉพาะ SPAs พิจารณาใช้ Authorization Code Grant พร้อม PKCE เพื่อแนวทางที่ปลอดภัยกว่า