Trải nghiệm thực tế với Token Vault khi xây dựng ứng dụng AI Anzen

07 tháng 4, 2026·3 phút đọc

Khi bắt đầu xây dựng Anzen cho cuộc thi hackathon Authorised to Act, tác giả đã đánh giá thấp độ khó của việc triển khai Token Vault từ Auth0. Bài viết chia sẻ những bài học "xương máu" về sự thay đổi trong SDK nextjs-auth0, quy trình trao đổi token phức tạp và các vấn đề tương thích với API Groq nhằm kiến tạo kiến trúc bảo mật tối ưu cho AI agent.

Trải nghiệm thực tế với Token Vault khi xây dựng ứng dụng AI Anzen

Khi bắt đầu xây dựng dự án Anzen cho cuộc thi hackathon "Authorised to Act", tôi từng nghĩ rằng việc triển khai Token Vault sẽ là phần dễ dàng nhất. Nhưng tôi đã sai.

Khái niệm của Token Vault rất đơn giản nhưng lại cực kỳ mạnh mẽ: thay vì để AI agent trực tiếp nắm giữ các token OAuth của GitHub, Gmail hay Slack, Auth0 sẽ lưu trữ chúng trong một "kho" (vault) an toàn. Khi cần, agent sẽ yêu cầu một token có phạm vi (scoped token), sử dụng nó cho tác vụ cụ thể, và sau đó token sẽ hết hạn. Không có thông tin đăng nhập nào được lưu trong ứng dụng, không có rủi ro bị đánh cắp dữ liệu, và không có quyền truy cập kiểu "tất cả hoặc không có gì" (all-or-nothing).

Tuy nhiên, quá trình triển khai thực tế mới là điều đáng bàn.

Sự thay đổi toàn diện trong nextjs-auth0 v4

Khám phá đầu tiên của tôi là nextjs-auth0 v4 là một SDK hoàn toàn khác so với phiên bản v3. Hàm quen thuộc handleAuth đã bị loại bỏ. Quy ước tệp middleware đã thay đổi. Tên các biến môi trường cũng đã khác biệt. Đường dẫn URL callback thậm chí đã chuyển từ /api/auth/callback sang /auth/callback. Không có điều nào trong số này được tài liệu hóa một cách rõ ràng, gây ra không ít khó khăn trong quá trình cài đặt ban đầu.

Quy trình trao đổi token (Token Exchange)

Thứ hai là sự phức tạp trong luồng trao đổi token. Việc gọi hàm getAccessToken() chỉ trả về một JWT của Auth0 chứ không phải là token của GitHub hay Slack mà bạn thực sự cần. Để lấy được token của nhà cung cấp dịch vụ, bạn phải thực hiện một yêu cầu POST riêng biệt tới điểm cuối token (token endpoint) với tham số grant_typeurn:ietf:params:oauth:grant-type:token-exchange, đi kèm với các tham số chủ thể (subject) và loại token được yêu cầu rất cụ thể. Đây chính là cơ chế trao đổi của Token Vault, và việc đưa các tham số này trở nên chính xác đã tốn khá nhiều thời gian gỡ lỗi (debugging).

Tương thích với Groq và Zod

Khám phá thứ ba liên quan đến khả năng tương thích với Groq. Các lược đồ (schema) của Zod bao gồm một trường meta $schema trong đầu ra JSON của chúng, nhưng API của Groq lại từ chối điều này, gây ra các lỗi "Failed to call a function" (Thất bại khi gọi hàm) một cách im lặng. Giải pháp là chuyển từ Zod sang sử dụng jsonSchema() có sẵn trong AI SDK để đảm bảo tính tương thích.

Kiến trúc bảo mật cho tương lai

Mặc dù gặp phải nhiều thách thức kỹ thuật, kiến trúc mà chúng tôi đạt được cuối cùng chính xác là những gì một AI agent cần mang tính biểu tượng: không lưu trữ bất kỳ chứng thực nào trong ứng dụng, quyền truy cập có phạm vi cho từng hành động, và người dùng luôn giữ quyền kiểm soát mọi bước đi. Đó chính là lời hứa của Token Vault, và xứng đáng với những nỗ lực để đạt được nó.

Bài viết được tổng hợp và biên soạn bằng AI từ các nguồn tin tức công nghệ. Nội dung mang tính tham khảo. Xem bài gốc ↗