การรับรองความถูกต้องแบบโปรแกรมมาติกร: คีย์ API, โทเค็นการเข้าถึงแบบส่วนบุคคล และการไหลของเครดิตเชียลของไคลเอนต์ OAuth

พื้นหลัง#

ในการพัฒนาซอฟต์แวร์ เมื่อเราต้องการเข้าถึงแหล่งข้อมูล API แบบโปรแกรมมาติกรผ่านคำสั่ง CLI หรือสร้างการสื่อสารระหว่างบริการแบ็กเอนด์ มีกลไกการรับรองความถูกต้องสามตัวที่มักจะถูกใช้โดยนักพัฒนา: คีย์ API, โทเค็นการเข้าถึงแบบส่วนบุคคล (PAT) และการไหลของเครดิตเชียลของไคลเอนต์ OAuth (ที่มีเครื่องหมายการค้าเป็น Machine-to-Machine ใน Logto) แต่ความแตกต่างระหว่างพวกมันคืออะไร? สถานการณ์ไหนที่ดีที่สุดสำหรับแต่ละวิธี? ในโพสต์บล็อกนี้เราจะพิจารณาความเหมือน ความแตกต่าง และให้ความคิดแนะนำว่าเมื่อไหร่ที่จะใช้แต่ละอย่างในสถานการณ์ต่างๆ

คำนิยาม#

• คีย์ API: สตริงง่าย ๆ ที่สามารถยืนยันการร้องขอของคุณไปยังแหล่งข้อมูล API
• โทเค็นการเข้าถึงแบบส่วนบุคคล (PAT): สตริงง่าย ๆ เช่นกัน แต่แทนตัวผู้ใช้เมื่อใช้ในการยืนยันการเข้าถึงแหล่งข้อมูล API เป็นการมอบหมายของผู้ใช้
• เครดิตเชียล Machine-to-Machine (Logto M2M): การไหลของเครดิตเชียลของไคลเอนต์ OAuth มาตรฐาน ซึ่งต้องการให้ไคลเอนต์ลงทะเบียนล่วงหน้า และต้องใช้ ID และความลับของไคลเอนต์เพื่อแลกเปลี่ยนโทเค็นการเข้าถึง ดังนั้นเครดิตเชียลของ Logto M2M แทนตัวไคลเอนต์ที่เชื่อถือได้ และธรรมชาติของการไหลของเครดิตเชียลของไคลเอนต์ OAuth ทำให้มันค่อนข้างซับซ้อนเมื่อใช้

ความเหมือนกัน#

1. วัตถุประสงค์ในการรับรองความถูกต้อง#

• ทั้งสามอย่าง คีย์ API, PAT, และ Logto M2M ทำหน้าที่หลักในการยืนยันตัวผู้ใช้หรือแอปพลิเคชันเพื่อเข้าถึงบริการหรือทรัพยากรเฉพาะ พวกเขาทำหน้าที่เป็นเครดิตเชียลเพื่อพิสูจน์อัตลักษณ์ของผู้ร้องขอ และมักจะใช้ในคำสั่ง CLI หรือสถานการณ์สื่อสารแบบแบ็กเอนด์กับแบ็กเอนด์

2. มาตรการความปลอดภัย#

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

ความแตกต่าง#

1. บริบทของผู้ใช้#

• คีย์ API ไม่ได้ระบุบุคคลหลัก และไม่มีการให้ข้อมูลสิทธิ์ ดังนั้นคีย์ API มักถูกใช้เพื่อเข้าถึงข้อมูลหรือทรัพยากรสาธารณะโดยไม่ระบุตัวตน บริการทั้งหมดไม่ได้รองรับการใช้คีย์ API
• PAT แทนตัวอัตลักษณ์ของผู้ใช้และจะเป็นตัวแทนของคุณเมื่อใช้ในการร้องขอไปยังแหล่งข้อมูล API ในบางระบบ PAT ไม่สามารถเข้าถึงบริการบางอย่างได้ เช่น การเผยแพร่แพ็กเกจ NuGet ไปยัง Azure Artifacts feed
• เครดิตเชียลของ Logto M2M สามารถใช้ได้เฉพาะกับไคลเอนต์ที่เชื่อถือได้ ไคลเอนต์ต้องลงทะเบียนล่วงหน้าเพื่อตรวจสอบการยืนยัน และเมื่อใช้เครดิตเชียลของ Logto M2M มันแทนตัวไคลเอนต์ที่เชื่อถือได้แทนตัวผู้ใช้ที่กำลังใช้งาน

2. ความละเอียดอ่อนของสิทธิ์#

• PAT และเครดิตเชียลของ Logto M2M มักให้การควบคุมสิทธิ์ที่ละเอียดกว่าเมื่อเปรียบเทียบกับคีย์ API ทำให้สามารถควบคุมรายละเอียดในสิ่งที่สามารถดำเนินการได้

3. รูปแบบโทเค็น#

• คีย์ API และ PAT มักเป็นสตริงประเภททึบแสง เรียบง่ายและธรรมดา
• โทเค็นการเข้าถึงที่ออกผ่านกลไกของ Logto M2M มักอยู่ในรูปแบบ JWT

4. กระบวนการอำนาจ#

• คีย์ API และ PAT เป็นสตริงทึบแสงที่ระบบสร้างขึ้น ไม่มีกระบวนการยืนยันการตรวจสอบอยู่ในระหว่างกระบวนการ ตัวอย่างเช่น คุณสามารถเรียกใช้ Google Cloud natural language API แบบนี้:

• Logto M2M ใช้การไหลของเครดิตเชียลของไคลเอนต์ OAuth 2.0 มาตรฐาน แต่ละไคลเอนต์ต้องได้รับคู่ของ client ID และ client secret ล่วงหน้า ซึ่งไคลเอนต์สามารถแลกเปลี่ยนเพื่อโทเค็นการเข้าถึงภายหลัง แล้วไคลเอนต์ใช้งานโทเค็นการเข้าถึงนั้นเพื่อเข้าถึงแหล่งข้อมูล API

เมื่อไรจะใช้แต่ละแบบ#

คีย์ API#

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

โทเค็นการเข้าถึงแบบส่วนบุคคล (PAT)#

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

Machine-to-Machine ของ Logto (Logto M2M)#

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

สรุป#

สรุปแล้ว การเลือกใช้คีย์ API, PATs, และ Logto M2M ขึ้นอยู่กับความต้องการเฉพาะของแอปพลิเคชันของคุณ ไม่ว่าจะเป็นการกระทำเฉพาะผู้ใช้ การสื่อสารระหว่างเครื่อง หรือการรวมกัน เปลือความจำเป็นด้านความปลอดภัยและการทำงานเพื่อกำหนดวิธีการรับรองความถูกต้องที่เหมาะสมที่สุดสำหรับกรณีการใช้งานของคุณ

กลไก Logto M2M อนุญาตให้ผู้ใช้ตั้งค่าการควบคุมสิทธิ์ที่ละเอียดผ่านคุณสมบัติ RBAC (การควบคุมการเข้าถึงโดยใช้บทบาท) เรายังวางแผนที่จะรองรับคีย์ API และ PAT ในอนาคต โปรดติดตามการอัปเดตคุณสมบัติของเรา!