[คู่มือ] ประเภทการให้สิทธิ์ OAuth 2.0

กรอบการทำงานการให้สิทธิ์ OAuth 2.0 สนับสนุนการให้สิทธิ์ที่ปลอดภัยโดยการนำเสนอวิธีการสำหรับแอปพลิเคชันในการเข้าถึงบัญชีผู้ใช้แบบจำกัดบนบริการ HTTP คู่มือนี้เจาะลึกประเภทการให้สิทธิ์ต่างๆ ที่ใช้ภายใน OAuth 2.0 ซึ่งกำหนดวิธีการที่แอปพลิเคชันไคลเอนต์รักษาความปลอดภัยโทเค็นการเข้าถึงเพื่อเข้าถึงทรัพยากรผู้ใช้บนเซิร์ฟเวอร์ทรัพยากร

ก่อนที่จะเจาะลึกลงไปในประเภทการให้สิทธิ์ของ OAuth 2.0 มาทบทวนสั้นๆ เกี่ยวกับ OAuth 2.0 คืออะไร

OAuth 2.0 คืออะไร

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

ประเภทการให้สิทธิ์ OAuth 2.0 คืออะไร

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

รายละเอียดของประเภทการให้สิทธิ์ OAuth 2.0 ที่แตกต่างกัน

1. Authorization Code Grant: การไหลนี้ใช้กันอย่างแพร่หลายให้ความสำคัญกับความปลอดภัย เกี่ยวข้องกับการแลกเปลี่ยนสี่ขั้นตอน:

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

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

ข้อเสีย: ต้องมีการเปลี่ยนเส้นทางหลายครั้งระหว่างแอปพลิเคชันไคลเอนต์ เซิร์ฟเวอร์การให้สิทธิ์ และเซิร์ฟเวอร์ทรัพยากร

2. Resource Owner Password Credentials Grant: วิธีนี้ใช้ข้อมูลประจำตัวในการเข้าสู่ระบบของผู้ใช้โดยตรง

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

ข้อดี: การใช้งานที่ตรงไปตรงมา เหมาะอย่างยิ่งสำหรับแอปพลิเคชันของบุคคลที่หนึ่งที่เชื่อถือได้

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

3. Client Credentials Grant: ออกแบบมาสำหรับแอปพลิเคชันที่ดำเนินการในนามของตนเอง ไม่ใช่ผู้ใช้เฉพาะ

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

ข้อดี: มีประสิทธิภาพสำหรับการโต้ตอบแบบเครื่องต่อเครื่องที่ไม่จำเป็นต้องมีส่วนร่วมของผู้ใช้

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

4. Implicit Grant: มักใช้ในแอปพลิเคชันมือถือหรือแอปพลิเคชันหน้าเดียว จะทำให้การไหลง่ายขึ้นโดยส่งคืนโทเค็นการเข้าถึงโดยตรงไปยังแอปพลิเคชันไคลเอนต์

ข้อดี: ประสบการณ์การใช้งานที่คล่องตัวเนื่องจากการเปลี่ยนเส้นทางเพียงครั้งเดียว

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

5. Refresh Token Grant: มีกลไกในการรับโทเค็นการเข้าถึงใหม่โดยไม่ต้องมีการตรวจสอบสิทธิ์ผู้ใช้อีกครั้ง

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

ข้อดี: ปรับปรุงประสบการณ์การใช้งานโดยการลดพรอมต์การเข้าสู่ระบบบ่อยครั้ง

ข้อเสีย: แนะนำโทเค็นอื่นที่ต้องจัดการอย่างปลอดภัย

วิธีเลือกประเภทการให้สิทธิ์ OAuth 2.0 ที่ถูกต้องสำหรับ API ของคุณ

1. ความต้องการด้านความปลอดภัย:

• เมื่อให้ความสำคัญกับความปลอดภัย: เลือก Authorization Code Grant การไหลนี้แยกตัวของรหัสการให้สิทธิ์และโทเค็นการเข้าถึง ลดความเสี่ยงแม้ว่ารหัสจะถูกสกัดกั้น
• หากคุณมีความกังวลด้านความปลอดภัยน้อยลง และมี แอปพลิเคชันไคลเอนต์ที่เชื่อถือได้: Resource Owner Password Credentials Grant อาจเหมาะสม แต่ดำเนินการด้วยความระมัดระวังเนื่องจากเกี่ยวข้องกับข้อมูลประจำตัวของผู้ใช้โดยตรง

2. ประสบการณ์ผู้ใช้:

• หากประสบการณ์ผู้ใช้ที่ราบรื่นเป็น สิ่งจำเป็น: Implicit Grant มอบการไหลที่รวดเร็วด้วยการเปลี่ยนเส้นทางเพียงครั้งเดียว อย่างไรก็ตาม โปรดทราบว่าโทเค็นการเข้าถึงที่เปิดเผยทำให้เกิดความกังวลด้านความปลอดภัย
• คุณพยายามที่จะสร้างสมดุลระหว่างความสะดวกสบายและความปลอดภัยหรือไม่? Authorization Code Grant มอบการประนีประนอมที่ดี แม้ว่าจะเกี่ยวข้องกับการเปลี่ยนเส้นทางมากขึ้นก็ตาม

3. ประเภทแอปพลิเคชันไคลเอนต์:

• แอปพลิเคชันไคลเอนต์มี ที่เก็บข้อมูลฝั่งเซิร์ฟเวอร์ที่ปลอดภัย (เช่น แอปพลิเคชันเว็บ) หรือไม่? Authorization Code Grant และ Client Credentials Grant เป็นตัวเลือกที่เป็นไปได้ทั้งคู่
• ไคลเอนต์เป็นแอปพลิเคชันสาธารณะ (เช่น แอปมือถือ) หรือไม่? ขอแนะนำให้ใช้ Authorization Code Grant with Proof Key for Code Exchange (PKCE) เพื่อเพิ่มความปลอดภัย PKCE ขจัดความเสี่ยงในการขโมยรหัสการให้สิทธิ์แม้ในสภาพแวดล้อมสาธารณะ
• การสื่อสารแบบเครื่องต่อเครื่อง? Client Credentials Grant ครองอำนาจสูงสุดที่นี่ โดยให้โทเค็นการเข้าถึงโดยตรงกับแอปพลิเคชันไคลเอนต์เอง

โปรดจำไว้ว่า:

• ข้อมูลที่ละเอียดอ่อน? ให้ความสำคัญกับความปลอดภัยเสมอและหลีกเลี่ยง Implicit Grant
• โทเค็นการรีเฟรช ปรับปรุงประสบการณ์การใช้งานโดยลดพรอมต์การเข้าสู่ระบบ แต่แนะนำเลเยอร์การจัดการอีกชั้นหนึ่ง

เลือกการตรวจสอบสิทธิ์ OAuth 2.0 สำหรับ API ของคุณด้วย Apidog

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

การสร้าง API ตั้งแต่เริ่มต้นด้วย Apidog

หากคุณต้องการเครื่องมือ API เพื่อช่วยคุณสร้าง API Apidog ช่วยคุณได้ ดูส่วนนี้เพื่อทำความเข้าใจว่าคุณสามารถใช้ Apidog เพื่อสร้าง API ได้อย่างไรในเวลาไม่นาน

เริ่มต้นด้วยการกดปุ่ม New API ดังที่แสดงในภาพด้านบน

ถัดไป คุณสามารถเลือกคุณลักษณะต่างๆ ของ API ได้ ในหน้านี้ คุณสามารถ:

• ตั้งค่าวิธีการ HTTP (GET, POST, PUT หรือ DELETE)
• ตั้งค่า URL API (หรือจุดสิ้นสุด API) สำหรับการโต้ตอบระหว่างไคลเอนต์กับเซิร์ฟเวอร์
• รวมพารามิเตอร์หนึ่ง/หลายรายการที่จะส่งผ่านใน URL API
• ให้คำอธิบายเกี่ยวกับฟังก์ชันการทำงานที่ API มีจุดมุ่งหมายเพื่อให้

เพื่อช่วยเหลือในการสร้าง API ในกรณีที่คุณสร้าง API เป็นครั้งแรก คุณอาจพิจารณาอ่านบทความเหล่านี้เพื่อทำความเข้าใจ แนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้าง REST API (หรือ API ทั่วไป):

การเลือกการตรวจสอบสิทธิ์ OAuth 2.0 ด้วย Apidog

ด้วยส่วนต่อประสานผู้ใช้ที่เรียบง่ายและใช้งานง่ายของ Apidog คุณสามารถเลือก OAuth 2.0 ได้อย่างง่ายดาย หรือประเภทการตรวจสอบสิทธิ์อื่นๆ ได้ในเวลาเพียงไม่กี่วินาที!

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

บทสรุป

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

การทำความเข้าใจประเภทการให้สิทธิ์เป็นทักษะที่จำเป็นสำหรับนักพัฒนาที่ทำงานกับ OAuth 2.0 ด้วยการใช้ประโยชน์จากความรู้ที่นำเสนอในคู่มือนี้ นักพัฒนาสามารถตัดสินใจได้อย่างชาญฉลาดเมื่อออกแบบกลไกการให้สิทธิ์ที่ปลอดภัยและมีประสิทธิภาพสำหรับแอปพลิเคชันของตน