งานตามกำหนดการหรือการเข้าสู่ระบบของมนุษย์: API ควรเห็นตัวตนแบบใด

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

สามประตูที่ดูเหมือนประตูเดียว

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

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

เส้นทางแบบโต้ตอบเป็นแม่แบบที่ไม่ดีสำหรับระบบอัตโนมัติ

การเขียนสคริปต์สำหรับการเข้าสู่ระบบของคนเป็นสิ่งล่อใจเพราะมันได้ผลหนึ่งครั้ง สคริปต์เก็บรหัสผ่าน อาจเก็บเมล็ดรหัสผ่านใช้ครั้งเดียว แล้วจึงพึ่งพาความท้าทายที่ออกแบบมาให้ต้องมีมนุษย์ แนวปฏิบัติด้านความปลอดภัยที่ดีที่สุดในปัจจุบันสำหรับ OAuth คือ RFC 9700 ห้ามการให้สิทธิ์แบบ resource-owner-password-credentials และอธิบายว่าเหตุใดจึงเข้ากันได้ไม่ดีกับการพิสูจน์ตัวตนแบบสองปัจจัยและหลายขั้นตอน

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

VPN ยังมีที่ทางตรงไหน

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

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

เปรียบเทียบทั้งสองดีไซน์อย่างตรงไปตรงมา

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

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

สิ่งที่ต้องตรวจสอบก่อนส่งมอบ

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

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

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