ไทย

api
ความปลอดภัย
การยืนยันตัวตน
PAT
คีย์ API
machine-to-machine

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

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

Guamian

Product & Design

7/26/2024

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ

เริ่มต้นใช้งาน

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

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

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

มาดูความเหมือนกันของทั้งสามก่อน

วัตถุประสงค์ด้านความปลอดภัย: วิธีการทั้งสามใช้เพื่อรักษาความปลอดภัยและควบคุมการเข้าถึง API บริการ หรือทรัพยากรต่าง ๆ พวกเขาทั้งหมดทำหน้าที่เป็นหนทางในการยืนยันตัวตนและ/หรืออนุญาต
วิธีการที่ใช้โทเค็น: แต่ละวิธีมักเกี่ยวข้องกับการใช้สตริงหรือโทเค็นที่มีลักษณะเฉพาะสำหรับการระบุตัวตน โทเค็นเหล่านี้มักจะส่งพร้อมกับการขอ API บ่อยครั้งในส่วนหัวหรือเป็นพารามิเตอร์ของการขอ
สามารถเพิกถอน: โทเค็นหรือคีย์ในทั้งสามวิธีสามารถเพิกถอนหรือทำให้เป็นโมฆะได้ หากถูกบุกรุกหรือต้องการใช้งานอีกต่อไป วิธีนี้ช่วยให้ตอบสนองต่อความปลอดภัยได้อย่างรวดเร็วโดยไม่ต้องเปลี่ยนระบบพื้นฐาน
การเข้าถึงแบบโปรแกรม: วิธีการทั้งสามสนับสนุนการเข้าถึงและสามารถใช้งานในแบบโปรแกรมสำหรับ API หรือบริการต่าง ๆ พวกเขาช่วยให้ระบบหรือแอปพลิเคชันต่าง ๆ สามารถทำงานอัตโนมัติและเชื่อมต่อกันได้
สามารถตรวจสอบได้: การใช้วิธีการยืนยันตัวตนเหล่านี้สามารถบันทึกและตรวจสอบได้ ช่วยให้สามารถติดตามการเข้าถึง API ตรวจสอบกิจกรรมที่น่าสงสัย และรายงานการปฏิบัติตามกฎระเบียบ
ปรับเปลี่ยนได้ตามการควบคุมการเข้าถึง: วิธีการทั้งสามสามารถปรับใช้ได้ด้วยระดับการควบคุมการเข้าถึงและการอนุญาตที่แตกต่างกัน สามารถปรับให้เข้ากับโมเดลความปลอดภัย และข้อกำหนดสถาปัตยกรรมต่าง ๆ
ความเป็นอิสระจากโปรโตคอล: แม้ว่ามักจะใช้กับ REST APIs แต่การใช้งานเหล่านี้สามารถใช้กับ API และโปรโตคอลชนิดต่าง ๆ ได้

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

ตอนนี้ มาพูดถึงความแตกต่างของพวกเขา โดยมุ่งเน้นไปที่กรณีการใช้งานและเวลาในการใช้แต่ละวิธีการ

ความแตกต่าง

คีย์ API

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

คีย์ API ทำงานอย่างไร?

คีย์ API ออกโดยผู้ให้บริการ API และมอบให้ผู้บริโภค API ที่ลงทะเบียน [1] ซึ่งรวมไว้กับการขอแต่ละครั้ง เซิร์ฟเวอร์ API จากนั้นจะตรวจสอบคีย์ API เพื่อยืนยันตัวตนของผู้บริโภคก่อนที่จะส่งคืนข้อมูลที่ร้องขอ

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

[1]: ผู้บริโภค API คือแอปพลิเคชัน บริการ หรือผู้ใช้ใด ๆ ที่โต้ตอบกับ API เพื่อเข้าถึงฟังก์ชันหรือข้อมูลของมัน พวกเขาส่งคำขอถึง API เพื่อทำการดำเนินการต่าง ๆ เช่น รับ, สร้าง, แก้ไข, หรือลบทรัพยากร ผู้บริโภค API สามารถเป็นเว็บแอปพลิเคชัน แอปมือถือ เซิร์ฟเวอร์อื่น ๆ หรือแม้แต่นักพัฒนารายบุคคลที่ใช้ API เพื่อเชื่อมต่อกับบริการอื่น ๆ หรือสร้างฟังก์ชันใหม่บนแพลตฟอร์มที่มีอยู่

Postman: คีย์ API คืออะไร?

กรณีการใช้งาน

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

ตัวอย่าง 1: การผนวกกับ Zapier

Zapier: เพิ่มการยืนยันตัวตนด้วยคีย์ API

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

Zapier

ตัวอย่าง 2: การผนวกกับ Stripe

Stripe ใช้ประโยชน์จากคีย์ API สำหรับการผนวกที่ปลอดภัยกับแพลตฟอร์มและแอปพลิเคชันต่าง ๆ ใช้ แดชบอร์ดนักพัฒนา เพื่อสร้าง แสดง ลบ และหมุนคีย์ API

Stripe

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

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

PATs ทำงานอย่างไร

การสร้างและการจัดการ: ผู้ใช้สร้าง PATs ผ่านการตั้งค่าบัญชีของพวกเขาในแพลตฟอร์มที่เกี่ยวข้อง
- ตัวอย่างเช่น ใน GitHub ผู้ใช้สามารถสร้าง PATs แบบละเอียดหรือแบบคลาสสิกด้วยสิทธิ์เฉพาะและวันที่หมดอายุ
- ในผลิตภัณฑ์ Atlassian เช่น Jira และ Confluence ผู้ใช้สามารถสร้าง PATs ได้จากการตั้งค่าโปรไฟล์โดยเลือกชื่อและการหมดอายุที่เป็นทางเลือก
การใช้งาน: PATs ใช้เป็นโทเค็นผู้ถือในส่วนหัวการอนุญาตของคำขอ API ซึ่งหมายความว่ามีการรวมไว้ในส่วนหัว HTTP เพื่อยืนยันคำขอ
- ทำให้การเข้าถึง API ทรัพยากรปลอดภัย อนุญาตให้ผู้ใช้ทำการกระทำต่าง ๆ เช่น การสร้าง การอ่าน การแก้ไข และการลบทรัพยากรขึ้นอยู่กับสิทธิ์ที่มอบให้กับโทเค็น
- PATs สามารถใช้ได้ในแอปพลิเคชันหลาย ๆ ภายในแพลตฟอร์มหนึ่งเดียว ให้วิธีการที่รวมไว้ในการจัดการการเข้าถึงและสิทธิ์ต่าง ๆ
การเพิกถอนและการตั้งค่าวันหมดอายุ:
- PATs ให้ความปลอดภัยที่เพิ่มขึ้นโดยอนุญาตให้ผู้ใช้เพิกถอนโทเค็นหากถูกบุกรุกโดยไม่ต้องเปลี่ยนรหัสผ่านบัญชี
- แพลตฟอร์มมักจะแนะนำให้ตั้งค่าการหมดอายุของ PATs เพื่อลดความเสี่ยงของโทเค็นที่มีอายุการใช้งานยาวนานถูกใช้ประโยชน์

กรณีการใช้งาน

มีสองสถานการณ์ทั่วไป,

การทำงานอัตโนมัติและการสคริปต์

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

ตัวอย่างเช่น ผู้ใช้ GitHub สามารถสร้าง PATs เพื่อยืนยันการดำเนินการ Git ผ่าน HTTPS และโต้ตอบกับ API REST ของ GitHub ซึ่งเป็นประโยชน์สำหรับผู้พัฒนาที่จำเป็นต้องทำงานอัตโนมัติ เช่น การโคลนที่เก็บ การผลักดันคอมมิท หรือการจัดการปัญหาและคำขอดึง

การผนวกกับแอปพลิเคชันภายนอก

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

ตัวอย่างเช่น ผู้จัดการโครงการใช้ PAT เพื่อผนวกระบบการจัดการโครงการกับระบบติดตามปัญหาภายนอก อนุญาตให้มีการแลกเปลี่ยนข้อมูลและความสัมพันธ์ข้อมูลที่ไม่สะดุด เช่น Atlassian (Jira และ Confluence)

สถานการณ์ข้างต้นมีลักษณะเหมือนเครื่องมือผู้พัฒนามากขึ้น PATs มีประโยชน์เฉพาะสำหรับผลิตภัณฑ์เหล่านี้หรือไม่? ไม่ นี่คือตัวอย่างเพิ่มเติมสองตัวอย่าง: หนึ่งคือระบบ CMS และอีกหนึ่งคือเครื่องมือเพิ่มประสิทธิผล

ตัวอย่าง 1: Contentful

Contentful: โทเค็นการเข้าถึงส่วนบุคคล

Contentful เป็นแพลตฟอร์ม CMS แบบไม่ต้องหัวที่เสนอ PATs เป็นทางเลือกแทนโทเค็น OAuth ในการเข้าถึง API การจัดการเนื้อหา (CMA) ของพวกเขา

คุณสมบัติสำคัญรวมถึง:

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

Contentful

ตัวอย่าง 2: Airtable

สร้างโทเค็นการเข้าถึงส่วนบุคคล | การสนับสนุน Airtable

Airtable - แพลตฟอร์มการทำงานร่วมกันบนคลาวด์ ดำเนินการ PATs สำหรับการเข้าถึง API

ระบบของพวกเขาอนุญาต:

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

Airtable

การยืนยันตัวตนจากเครื่องสู่เครื่อง (M2M)

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

แอปพลิเคชันจากเครื่องต่อเครื่อง (M2M) ตอนนี้รับใช้ Client Credentials Flow ซึ่งถูกกำหนดใน โปรโตคอลการอนุญาต OAuth 2.0 RFC 6749 มันยังสามารถสนับสนุนโปรโตคอลมาตรฐานที่คล้ายกันได้ ใช่ การยืนยันตัวตน M2M มีความเข้มงวดกว่าเมื่อเปรียบเทียบกับ PATs และคีย์ API ในมาตรฐานเปิด

มันยืนยันตัวตนของแอปพลิเคชันหรือบริการเอง ไม่ใช่ผู้ใช้ และมักจะใช้ JWT (JSON Web Tokens) สำหรับการยืนยันตัวตนแบบไร้สถานะ วิธีนี้ให้วิธีการที่ปลอดภัยสำหรับบริการที่จะโต้ตอบกันในระบบกระจาย

การยืนยันตัวตนจากเครื่องสู่เครื่องทำงานอย่างไร

มันทำตามกระบวนการที่คล้ายกัน:

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

กรณีการใช้งาน

นี่คือตัวอย่างสั้น ๆ ของการใช้การยืนยันตัวตนจากเครื่องสู่เครื่อง (M2M) สำหรับการสื่อสารระหว่างแบ็คเอนด์กับแบ็คเอนด์:

สถานการณ์: บริการ A จำเป็นต้องเข้าถึงข้อมูลจาก API ของบริการ B

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

กระบวนการนี้อนุญาตให้มีการสื่อสารอัตโนมัติที่ปลอดภัยระหว่างบริการ A และบริการ B โดยไม่มีการแทรกแซงของผู้ใช้ โดยใช้ OAuth 2.0 client credentials flow

การสื่อสารจากอุปกรณ์ต่ออุปกรณ์

การสื่อสารจากอุปกรณ์ถึงอุปกรณ์ โดยเฉพาะอย่างยิ่งในบริบทของ IoT (Internet of Things) พึ่งพาหนักมากที่การยืนยันตัวตนจากเครื่องสู่เครื่อง (M2M) เพื่อให้มั่นใจว่าการแลกเปลี่ยนข้อมูลนั้นปลอดภัยและมีประสิทธิภาพ

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

สรุปสำคัญ

โอเค คุณอ่านบทความนี้มาถึงตอนจบแล้ว ขอสรุปสั้น ๆ ได้ไหม ได้แน่นอน! ต่อไปนี้คือสิ่งที่น่าสนใจ:

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

ลองใช้ Logto Cloud ฟรี

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

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

คีย์ API#

คีย์ API ทำงานอย่างไร?#

กรณีการใช้งาน#

ตัวอย่าง 1: การผนวกกับ Zapier#

ตัวอย่าง 2: การผนวกกับ Stripe#

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

PATs ทำงานอย่างไร#

กรณีการใช้งาน#

ตัวอย่าง 1: Contentful#

ตัวอย่าง 2: Airtable#

การยืนยันตัวตนจากเครื่องสู่เครื่อง (M2M)#

การยืนยันตัวตนจากเครื่องสู่เครื่องทำงานอย่างไร#

กรณีการใช้งาน#

สรุปสำคัญ#

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

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

คีย์ API#

คีย์ API ทำงานอย่างไร?#

กรณีการใช้งาน#

ตัวอย่าง 1: การผนวกกับ Zapier#

ตัวอย่าง 2: การผนวกกับ Stripe#

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

PATs ทำงานอย่างไร#

กรณีการใช้งาน#

ตัวอย่าง 1: Contentful#

ตัวอย่าง 2: Airtable#

การยืนยันตัวตนจากเครื่องสู่เครื่อง (M2M)#

การยืนยันตัวตนจากเครื่องสู่เครื่องทำงานอย่างไร#

กรณีการใช้งาน#

สรุปสำคัญ#

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