Sebastian Petrus

Posted on Aug 26 Originally published at apidog.com

OAuth cho Agent AI: Bảo mật ủy quyền thay mặt người dùng

OAuth 2.0 cho AI Agent: ủy quyền thay mặt người dùng an toàn

Đặc vụ của bạn có thể cần đọc lịch, gửi tin nhắn từ tài khoản của người dùng hoặc tạo yêu cầu hỗ trợ dưới tên của họ. Dùng một tài khoản dịch vụ có quyền rộng là cách nhanh nhất, nhưng mọi hành động sẽ chỉ hiện dưới dạng “tích hợp”, không xác định được người dùng đã yêu cầu, và một thông tin đăng nhập bị lộ có thể làm lộ toàn bộ tài khoản.

Dùng thử Apidog ngay hôm nay

Cách đúng là ủy quyền được ủy nhiệm (delegated authorization): người dùng cấp cho đặc vụ một mã thông báo có phạm vi, có thể thu hồi; đặc vụ hành động thay mặt người dùng và nhật ký kiểm toán vẫn ghi rõ danh tính của họ.

Đó là lý do OAuth 2.0 được xây dựng. Thách thức với AI agent là OAuth thường giả định có trình duyệt và một người nhấp Cho phép, trong khi agent có thể chạy nền lúc 3 giờ sáng.

Bài viết này trình bày:

Luồng OAuth phù hợp cho AI agent.
Cách thiết kế và lưu trữ scope, token.
Cách xử lý refresh và revoke.
Cách kiểm thử toàn bộ quy trình mà không cần tài khoản thật.

Nếu bạn đang cân nhắc giữa API key và delegated authorization, hãy bắt đầu với bài API key và OAuth.

Apidog giúp kiểm thử các nhánh thường bị bỏ qua, chẳng hạn token hết hạn hoặc bị thu hồi, trước khi agent gặp chúng trong production.

Tài khoản dịch vụ hay delegated access?

Hai mô hình này thất bại theo những cách khác nhau, vì vậy hãy chọn dựa trên quyền sở hữu dữ liệu.

Tài khoản dịch vụ

Tài khoản dịch vụ là danh tính riêng của agent, với quyền riêng. Mô hình này phù hợp khi agent làm việc trên tài nguyên của chính bạn:

Đọc cơ sở dữ liệu nội bộ.
Gọi các dịch vụ của tổ chức.
Chạy job theo lịch trên hạ tầng của bạn.

Hãy giới hạn quyền chặt chẽ và xoay vòng credential, tương tự nguyên tắc trong bài API key đặc quyền tối thiểu cho AI agent.

Delegated access

Delegated access cho phép agent hành động như một người dùng cụ thể, với đúng quyền của người dùng đó và không hơn. Đây là lựa chọn cần thiết khi dữ liệu thuộc về người khác.

Mô hình này có ba lợi ích chính:

Người dùng biết họ đã cấp quyền gì.
Người dùng có thể thu hồi quyền.
Nhật ký ghi nhận hành động dưới danh tính người dùng.

Mô hình nên tránh

Không nên dùng một tài khoản dịch vụ có quyền truy cập toàn tổ chức để hành động “như” từng người dùng. Cách này có thể hoạt động về mặt kỹ thuật, nhưng:

Một credential bị lộ sẽ ảnh hưởng đến mọi người.
Không thể thu hồi quyền theo từng người dùng.
Nhật ký kiểm toán không phản ánh đúng người thực sự đã cấp quyền.

Ranh giới đơn giản là:

Nếu dữ liệu thuộc về người dùng có thể hợp lý khi thu hồi quyền, hãy dùng delegated access. Nếu dữ liệu thuộc về hệ thống của bạn, hãy dùng tài khoản dịch vụ.

Luồng OAuth nào phù hợp với AI agent?

OAuth 2.0 được định nghĩa trong RFC 6749. Với AI agent, các luồng sau là quan trọng nhất.

Authorization Code với PKCE

Đây là luồng tiêu chuẩn để agent hành động thay mặt người dùng:

Người dùng được chuyển hướng đến nhà cung cấp.
Người dùng xem và phê duyệt các scope.
Dịch vụ của bạn đổi authorization code lấy token.
Dịch vụ lưu refresh token để agent sử dụng về sau.

PKCE bảo vệ quá trình trao đổi code và hiện là lựa chọn mặc định cho các loại client, theo OAuth 2.0 Security Best Current Practice.

Xem hướng dẫn OAuth 2.0 Authorization Code Grant để triển khai từng bước.

Điểm quan trọng với agent:

Luồng này chỉ chạy một lần tại thời điểm kết nối.
Người dùng cần có mặt để phê duyệt.
Agent chạy nền không tự thực hiện lại luồng này.
Agent sử dụng refresh token được tạo ra từ lần kết nối ban đầu.

Hãy tách riêng hai thời điểm:

Connection time: có trình duyệt và sự đồng ý của con người.
Run time: agent dùng delegated access đã được cấp.

Client Credentials

Đây là luồng máy-tới-máy, không có người dùng liên quan. Nó phù hợp với tài khoản dịch vụ và không phù hợp khi agent cần hành động như một người dùng, vì không có ai để đồng ý.

Device Authorization Grant

Luồng này dành cho agent chạy trên máy không có trình duyệt, chẳng hạn:

CLI agent.
Máy chủ headless.
Thiết bị hoặc môi trường không có giao diện đồ họa.

Người dùng nhận một mã, sau đó phê duyệt trên điện thoại hoặc một thiết bị khác.

Token Exchange

RFC 8693 cho phép dịch vụ đổi một token thành token có phạm vi hẹp hơn.

Đây là cơ chế phù hợp cho hệ thống đa agent:

Người dùng cấp quyền rộng hơn cho hệ thống.
Agent điều phối đổi token đó lấy token giới hạn cho từng nhiệm vụ.
Agent phụ không bao giờ nhận token gốc của người dùng.

Cách này giúp phân tách credential cho từng agent và phù hợp với các nguyên tắc trong bài chuyển giao đa agent.

Giới hạn scope theo từng agent

Scope là nơi delegated access tạo ra giá trị lớn nhất, nhưng cũng là nơi nhiều triển khai yêu cầu quá mức.

Chỉ yêu cầu quyền agent thực sự cần

Một agent lập lịch có thể chỉ cần:

Đọc trạng thái rảnh/bận.
Tạo hoặc cập nhật lịch.

Agent đó không cần quyền đọc email, danh bạ hoặc tệp. Người dùng phải đọc màn hình đồng ý, nên danh sách scope dài sẽ làm giảm niềm tin và mở rộng phạm vi ảnh hưởng.

Tham khảo bài OAuth 2.0 scopes là gì?.

Yêu cầu quyền tăng dần

Hãy bắt đầu với scope tối thiểu. Chỉ yêu cầu thêm quyền khi người dùng sử dụng một tính năng cần đến nó.

Một yêu cầu gắn với hành động cụ thể thường:

Dễ được người dùng phê duyệt hơn.
Dễ giải thích hơn.
Dễ kiểm toán hơn.

Mỗi agent một token riêng

Nếu agent nghiên cứu và agent thanh toán cùng hoạt động cho một người dùng, hãy cấp hai token với scope khác nhau thay vì chia sẻ một token.

Khi đó:

Agent nghiên cứu bị xâm phạm không thể hoàn tiền.
Nhật ký xác định được agent nào đã hành động.
Có thể thu hồi một integration mà không ảnh hưởng integration còn lại.

Ưu tiên read-only

Hãy ưu tiên scope đọc theo mặc định và yêu cầu leo thang rõ ràng cho quyền ghi. Với hành động phá hoại hoặc có tác động lớn, hãy kết hợp token với một cổng phê duyệt như trong bài AI agent guardrails.

Token trả lời câu hỏi:

Agent có được phép làm việc này không?

Cổng phê duyệt trả lời câu hỏi:

Agent có nên làm việc này ngay bây giờ không?

Lưu trữ, refresh và revoke token

Token là credential. Hãy xử lý chúng như credential.

Lưu trữ an toàn

Mã hóa refresh token khi không sử dụng.
Lưu trữ riêng theo từng người dùng và từng agent.
Không ghi token vào log.
Không đưa token vào prompt.
Không để model nhìn thấy token.

Một token xuất hiện trong context có thể bị lưu trong trace, log của nhà cung cấp hoặc bản tóm tắt.

Bài theo dõi tool call của AI agent trình bày cách redact dữ liệu ngay tại ranh giới HTTP.

Tự động refresh

Access token thường có thời gian sống ngắn. Agent không nên tự xử lý logic này. Hãy đặt một token manager trước HTTP client:

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

Khi API trả về 401 do access token hết hạn:

Refresh token.
Lưu refresh token mới nếu nhà cung cấp xoay vòng token.
Thử lại request đúng một lần.
Nếu vẫn thất bại, dừng và báo lỗi.

Xử lý refresh token rotation

Nhiều nhà cung cấp cấp refresh token mới sau mỗi lần refresh và vô hiệu hóa token cũ. Vì vậy:

Lưu token mới ngay lập tức.
Thực hiện việc lưu trong cùng giao dịch với thao tác tiêu thụ token cũ nếu có thể.
Tuần tự hóa refresh theo từng người dùng và scope.

Hai lần refresh đồng thời có thể cạnh tranh; một lần sẽ thất bại dù token ban đầu vẫn hợp lệ.

Xử lý revoke

Quyền có thể bị thu hồi bởi:

Người dùng.
Quản trị viên.
Nhà cung cấp khi tài khoản bị xóa.
Chính sách hết hạn hoặc không hoạt động.

Hãy coi 401 và 403 là lỗi cuối cùng, không phải lỗi có thể retry:

401: token không hợp lệ hoặc không còn hiệu lực.
403: token hợp lệ nhưng thiếu scope hoặc không được phép thực hiện hành động.

Không retry lỗi xác thực. Hãy trả về thông báo rõ ràng, bao gồm người dùng và scope liên quan, theo các nguyên tắc trong bài thiết kế API error message cho AI agent.

Giải quyết vấn đề consent

OAuth cần con người đồng ý, còn agent thường chạy tự động. Cách giải quyết là tách connection khỏi execution.

Connection time

Người dùng phê duyệt một lần trong trình duyệt.
Hệ thống lưu refresh token được mã hóa.
Hệ thống ghi lại user ID, agent ID và scope đã cấp.

Run time

Agent sử dụng delegated access đã lưu.
Không cần người dùng tương tác.
Token manager tự refresh khi cần.
Agent dừng nếu quyền đã hết hạn hoặc bị thu hồi.

Cần lập kế hoạch cho hai giới hạn:

Authorization có thể hết hạn: phát hiện và thông báo cho người dùng, thay vì để job thất bại âm thầm mỗi đêm.
Scope có giới hạn: nếu agent cần scope chưa từng được cấp, hãy yêu cầu người dùng đồng ý; không tự động leo thang.

Với hành động có rủi ro cao, hãy thêm bước phê duyệt tại thời điểm thực thi. Quyền truy cập và quyết định thực hiện là hai vấn đề khác nhau.

Kiểm thử OAuth trước khi agent gặp lỗi

Đường dẫn xác thực thường ít được kiểm thử nhất vì kiểm thử thủ công đòi hỏi đi qua màn hình của nhà cung cấp.

Hãy xây dựng ít nhất năm trường hợp:

Luồng thành công: access token hợp lệ và request thành công.
Access token hết hạn: API trả 401, token manager refresh, retry một lần và request thành công.
Refresh token bị thu hồi: refresh trả invalid_grant; agent dừng và yêu cầu kết nối lại.
Thiếu scope: API trả 403; agent không retry và chỉ rõ scope còn thiếu.
Refresh đồng thời: hai request của cùng một người dùng chạy cùng lúc; chỉ một request được refresh.

Hãy chạy các trường hợp này với mock object hoặc mock server. Trong Apidog, bạn có thể:

Định nghĩa token endpoint.
Định nghĩa các protected endpoint.
Mô phỏng status code và error body.
Chạy toàn bộ ma trận mà không chạm vào nhà cung cấp thật.

Xem thêm bài chạy AI agent với mock API thay vì production và hướng dẫn kiểm thử OAuth 2 API.

Ba ví dụ tích hợp

1. Trợ lý lịch

Agent cần đọc trạng thái rảnh/bận và đặt cuộc họp cho người dùng.

Thiết kế phù hợp:

Delegated access.
Hai scope tối thiểu.
Consent trong trình duyệt tại thời điểm kết nối.
Chạy nền bằng refresh token sau đó.

Trường hợp cần kiểm thử kỹ nhất là revoke. Khi người dùng ngắt kết nối integration, job chạy ban đêm phải dừng thay vì retry một authorization đã chết trong nhiều ngày.

2. Agent hỗ trợ trong hộp thư chung

Agent xử lý ticket thuộc về một nhóm.

Dùng tài khoản chung của nhóm có thể chấp nhận nếu tài nguyên thực sự thuộc về nhóm, nhưng mọi phản hồi sẽ trông giống nhau trong audit log.

Thiết kế tốt hơn là:

Một bot identity với scope riêng.
Ghi lại user nào đã kích hoạt hoạt động.
Tách bot identity khỏi người yêu cầu.

Cách này duy trì khả năng quy trách nhiệm mà không giả vờ agent là một người cụ thể.

3. Agent vận hành nội bộ

Agent khởi động lại service và đọc dashboard trên hạ tầng của chính bạn.

Không có dữ liệu người dùng và không cần delegated access. Tài khoản dịch vụ với scope hẹp là lựa chọn phù hợp. Trọng tâm lúc này là:

Giới hạn blast radius.
Xoay vòng credential.
Kiểm soát quyền truy cập nội bộ.

Ghi nhận đầy đủ trách nhiệm

Delegated authorization trả lời:

Agent hành động thay mặt cho ai?

Nó không trả lời:

Ai đã yêu cầu agent làm việc đó?

Bạn cần lưu cả hai danh tính.

Ở lớp quản lý công việc, hãy ghi lại:

Người yêu cầu.
Agent hoặc crew được giao.
User identity mà agent hành động thay mặt.
Scope và token identifier được sử dụng.
Kết quả của tool call.

Một nhiệm vụ Sharkly có thể lưu người chịu trách nhiệm cùng với agent hoặc crew được giao. Xem thêm Sharkly và tài liệu Sharkly.

Sau một sự cố, câu hỏi kiểm toán thường là “ai đã yêu cầu việc này?”. Chỉ có access token thì không trả lời được câu hỏi đó.

Không để model nhìn thấy credential

Một nguyên tắc kiến trúc có thể ngăn phần lớn sự cố:

Model không bao giờ được nhìn thấy token.

Token phải được chèn bởi executor ở lớp HTTP, sau khi model đã chọn tool và tạo arguments.

Do đó:

Tool schema không có tham số token.
Prompt không chứa credential.
Response trả về cho model không bao gồm Authorization header.
Log và trace phải redact token trước khi lưu.

Điều này đặc biệt quan trọng với AI agent vì dữ liệu trong context có thể:

Được tóm tắt.
Được chuyển sang agent khác.
Bị ghi vào trace.
Xuất hiện trong error message.
Được trả lại cho người dùng.

Danh tính người dùng cũng phải do executor xác định. Executor biết run hiện tại hành động thay mặt ai và tự chọn token tương ứng. Không nên để model tự đặt user ID, vì đó là một quyết định ủy quyền được giao cho thành phần khó dự đoán nhất trong hệ thống.

Checklist triển khai

Dùng delegated access khi dữ liệu thuộc về người dùng.
Chỉ dùng tài khoản dịch vụ cho tài nguyên của hệ thống.
Dùng Authorization Code với PKCE khi kết nối.
Dùng Device Authorization cho máy không có giao diện đồ họa.
Thiết kế scope theo từng agent, tối thiểu và tăng dần.
Dùng token exchange cho agent phụ thay vì chia sẻ token gốc.
Mã hóa refresh token khi lưu trữ.
Không đưa token vào prompt, log hoặc trace.
Để token manager xử lý refresh.
Tuần tự hóa refresh theo từng người dùng.
Lưu refresh token mới sau rotation.
Coi 401 và 403 là lỗi cuối cùng.
Hiển thị người dùng và scope trong thông báo lỗi.
Phát hiện authorization đã hết hạn và yêu cầu kết nối lại.
Bảo vệ hành động rủi ro cao bằng approval gate.
Kiểm thử cả năm kịch bản OAuth với mock trong CI.
Ghi lại cả người yêu cầu và user identity được impersonate.

Delegated authorization phức tạp hơn shared key, nhưng mang lại hai khả năng quan trọng khi agent hành động thay mặt người khác: người dùng có thể thu hồi quyền, và audit log cho biết ai đã làm gì.

Bạn có thể tải xuống Apidog để xây dựng token flow và kiểm thử các nhánh lỗi trước khi agent chạy không giám sát.

Câu hỏi thường gặp

Agent có thể tự hoàn thành OAuth consent flow không?

Không, và agent cũng không nên cố làm vậy. Consent yêu cầu một người quyết định cấp quyền nào.

Hãy để người dùng phê duyệt một lần qua luồng trình duyệt thông thường. Sau đó agent sử dụng authorization đã được cấp.

Mỗi agent có nên có OAuth client riêng không?

Nên tách OAuth client theo từng product integration và tách token theo từng agent, thường thông qua token exchange.

Client riêng hữu ích khi:

Nhà cung cấp giới hạn rate theo client.
Bạn muốn revoke từng integration độc lập.
Mỗi integration có vòng đời hoặc owner khác nhau.

Nếu refresh token bị rotation và tôi bỏ lỡ token mới thì sao?

Người dùng sẽ bị khóa và phải kết nối lại.

Hãy lưu refresh token mới trong cùng giao dịch với việc tiêu thụ token cũ, đồng thời tuần tự hóa refresh theo từng người dùng để hai agent không cạnh tranh.

Có an toàn khi để model nhìn thấy access token không?

Không. Access token thuộc về lớp HTTP và phải được executor chèn vào request.

Bất cứ dữ liệu nào model nhìn thấy đều có thể xuất hiện trong trace, bản tóm tắt hoặc response. Nguyên tắc này cũng áp dụng cho API key đặc quyền tối thiểu cho AI agent.

Làm thế nào biết agent nào đã làm gì?

Ghi lại trên mỗi request:

User ID.
Agent name hoặc ID.
Scope đã sử dụng.
Token identifier.

Không bao giờ ghi chính token. Bài theo dõi tool call của AI agent có thêm mẫu log phù hợp.

Nếu nhà cung cấp không hỗ trợ token exchange thì sao?

Hãy lưu authorization riêng cho từng agent nếu nhà cung cấp cho phép nhiều authorization.

Nếu không thể, hãy đặt giới hạn scope tại API gateway của bạn để request của từng agent được lọc theo hoạt động được phép trước khi rời khỏi mạng nội bộ.