OAuth สำหรับ AI Agent: ทำงานแทนผู้ใช้อย่างปลอดภัย

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

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

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

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

บัญชีบริการ หรือ การเข้าถึงแบบมอบสิทธิ์

เลือกอย่างรอบคอบ เพราะโมเดลทั้งสองมีข้อบกพร่องที่แตกต่างกัน

บัญชีบริการ (service account) คือตัวตนของอะเจนต์ของคุณเอง โดยมีสิทธิ์ของตัวเอง เหมาะสำหรับงานที่อะเจนต์ทำในนามของคุณ: การอ่านฐานข้อมูลของคุณเอง, การเรียกใช้บริการภายในของคุณเอง, การรันงานตามกำหนดเวลาบนโครงสร้างพื้นฐานของคุณ กำหนดขอบเขตให้แคบที่สุด ดังเช่นในบทความของเราเกี่ยวกับ คีย์ API ที่มีสิทธิ์น้อยที่สุดสำหรับอะเจนต์ และหมุนเวียน (rotate) มัน

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

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

โฟลว์ใดที่เหมาะกับเอเจนต์

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

Authorization code with PKCE. โฟลว์มาตรฐานสำหรับการทำหน้าที่เป็นผู้ใช้ ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังผู้ให้บริการ อนุมัติขอบเขต และบริการของคุณจะแลกเปลี่ยนโค้ดเป็นโทเค็น PKCE ปกป้องการแลกเปลี่ยนและเป็นคำแนะนำเริ่มต้นสำหรับไคลเอ็นต์ทุกประเภทแล้ว ตาม OAuth 2.0 Security Best Current Practice คำแนะนำของเราเกี่ยวกับ การให้สิทธิ์ด้วยรหัสยืนยันตัวตน ครอบคลุมกลไกทีละขั้นตอน

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

Client credentials. การสื่อสารระหว่างเครื่องกับเครื่อง ไม่มีผู้ใช้เกี่ยวข้อง เหมาะสำหรับบัญชีบริการและไม่ถูกต้องสำหรับการทำหน้าที่เป็นผู้ใช้ เพราะไม่มีผู้ใช้ที่จะให้ความยินยอม

Device authorization grant. สำหรับอะเจนต์บนเครื่องที่ไม่มีเบราว์เซอร์ ผู้ใช้จะได้รับโค้ดและอนุมัติบนโทรศัพท์ของตน มีประโยชน์สำหรับอะเจนต์ CLI และสภาพแวดล้อมที่ไม่มีส่วนหัว (headless environments)

Token exchange. RFC 8693 ช่วยให้บริการสามารถแลกโทเค็นเป็นโทเค็นที่แคบลงได้ นี่คือวิธีที่คุณให้โทเค็นแก่ซับเอเจนต์ที่จำกัดขอบเขตสำหรับงานเดียว โดยได้มาจากสิทธิ์ที่กว้างกว่าของผู้ใช้ โดยไม่ต้องให้โทเค็นเดิม หากคุณใช้ระบบหลายอะเจนต์ นี่คือกลไกที่ทำให้ข้อมูลรับรองต่ออะเจนต์สามารถใช้งานได้จริง และสอดคล้องกับกฎขอบเขตในบทความของเราเกี่ยวกับ การส่งมอบงานระหว่างหลายอะเจนต์

กำหนดขอบเขตอย่างจำกัด และตามแต่ละเอเจนต์

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

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

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

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

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

จัดเก็บ รีเฟรช และเพิกถอน

โทเค็นคือข้อมูลประจำตัว ดังนั้นจงปฏิบัติต่อมันเหมือนข้อมูลประจำตัว

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

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

class TokenManager:
    def __init__(self, store, provider):
        self.store, self.provider = store, provider

    def access_token(self, user_id, agent_scope):
        rec = self.store.get(user_id, agent_scope)
        if rec.expires_in() > 60:
            return rec.access_token
        fresh = self.provider.refresh(rec.refresh_token, scope=agent_scope)
        self.store.save(user_id, agent_scope, fresh)   # rotation: store the new refresh token
        return fresh.access_token

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

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

ปัญหาความยินยอม

ส่วนที่น่าอึดอัดของเอเจนต์บวกกับ OAuth: การยินยอมต้องใช้มนุษย์ และเอเจนต์ทำงานโดยไม่มีผู้ดูแล

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

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

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

ทดสอบโฟลว์ก่อนที่เอเจนต์จะใช้งาน

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

สร้างกรณีเหล่านี้ห้ากรณี:

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

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

สามการผสานรวมและสิ่งที่พวกเขาต้องการ

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

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

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

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

รักษาการระบุผู้รับผิดชอบที่เป็นมนุษย์ไว้

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

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

อย่าให้โมเดลถือข้อมูลรับรอง

กฎทางสถาปัตยกรรมหนึ่งข้อป้องกันเหตุการณ์การยืนยันตัวตนส่วนใหญ่ในระบบเอเจนต์: โมเดลไม่เคยเห็นโทเค็น

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

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

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

รายการตรวจสอบ

• การเข้าถึงแบบมอบสิทธิ์ทุกที่ที่ข้อมูลเป็นของผู้ใช้ บัญชีบริการสำหรับทรัพยากรของคุณเองเท่านั้น
• รหัสยืนยันตัวตนพร้อม PKCE ณ เวลาเชื่อมต่อ, สิทธิ์อุปกรณ์สำหรับเครื่องที่ไม่มีส่วนหัว (headless machines)
• ขอบเขตที่ร้องขอต่อเอเจนต์, น้อยที่สุด, ยกระดับอย่างค่อยเป็นค่อยไป
• ซับเอเจนต์จะได้รับโทเค็นที่แลกเปลี่ยนมา ไม่ใช่สำเนาของสิทธิ์ของผู้ใช้
• โทเค็นรีเฟรชที่เข้ารหัสเมื่อจัดเก็บ และไม่เคยอยู่ในพรอมต์ บันทึก หรือร่องรอย
• การรีเฟรชที่จัดการโดยผู้จัดการโทเค็น, จัดลำดับต่อผู้ใช้, การหมุนเวียนที่คงอยู่
• 401 และ 403 ถือเป็นข้อผิดพลาดสุดท้าย โดยมีข้อความระบุชื่อผู้ใช้และขอบเขต
• ตรวจพบสิทธิ์ที่หมดอายุและแจ้งให้ผู้ใช้ทราบ ไม่พยายามซ้ำทุกคืน
• การดำเนินการที่มีความเสี่ยงสูงถูกควบคุมด้วยการอนุมัติเพิ่มเติมจากโทเค็น
• ทดสอบสถานการณ์การยืนยันตัวตนทั้งห้ากรณีกับ mocks ใน CI

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

คำถามที่พบบ่อย

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

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

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

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

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

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