Nhiều khía cạnh của OAuth 2.0 Token Exchange

• Một cơ chế dựa trên tiêu chuẩn để chuyển đổi một security token thành token khác, là đặc tả mở rộng của OAuth 2.0 được định nghĩa trong RFC 8693
• Biến authorization server thành Security Token Service (STS), nơi xác thực token do client gửi lên và phát hành token mới phù hợp với ngữ cảnh, đối tượng đích (audience) và mục đích khác
• Về cách hoạt động, có thể chia thành hai chế độ chính là Impersonation và Delegation
• Mỗi trường hợp sử dụng khác nhau như impersonation của quản trị viên, chuyển đổi giao thức, chuỗi gọi dịch vụ, federation ID đều có các đánh đổi và tác động bảo mật riêng
• Khi AI agent ngày càng phổ biến, các tác vụ đi qua nhiều dịch vụ và nhà cung cấp về bản chất trở thành chuỗi ủy quyền, khiến token exchange càng quan trọng hơn

---

Token Exchange là gì

• Client gửi subject_token (token đại diện cho người dùng/thực thể là chủ thể của yêu cầu), và có thể tùy chọn gửi thêm actor_token (bên thực hiện việc trao đổi), rồi nhận về token mới phù hợp với ngữ cảnh đích
• Việc chuyển tiếp nguyên token hiện có hoặc tạo token mới theo cách tùy biến thoạt nhìn có vẻ trực quan, nhưng cả hai đều gây ra vấn đề nghiêm trọng, nên đặc tả này được tạo ra để giải quyết điều đó

• Hai chế độ hoạt động cơ bản

  • Impersonation: bên yêu cầu nhận một token không thể phân biệt với chủ thể gốc, nên dịch vụ downstream không thể biết đó là người dùng thật hay bên đang giả danh
  • Delegation: bảo toàn danh tính của cả hai chủ thể, cho phép dịch vụ downstream nhận biết cả người dùng và bên thực thi thay mặt thông qua claim act (actor) trong token mới
  • Impersonation mạnh nhưng thiếu minh bạch, Delegation có ràng buộc hơn nhưng có thể audit — lựa chọn này quyết định tư thế bảo mật và khả năng truy vết

Impersonation của quản trị viên (Administrative Impersonation)

• Khi cần chẩn đoán vấn đề dữ liệu hiển thị sai trên dashboard của khách hàng, kỹ sư hỗ trợ phải xem đúng màn hình đó với cùng quyền hạn và quyền truy cập dữ liệu như khách hàng
• Quản trị viên đổi token của mình sang token đại diện cho danh tính khách hàng; token kết quả chứa claim sub, scope và audience của khách hàng, nên từ góc nhìn của ứng dụng, yêu cầu được nhận diện như thể do khách hàng gửi
• Trong trường hợp này, yêu cầu chỉ dùng subject_token (người dùng bị giả danh) và không cung cấp actor_token — vì mục tiêu là impersonation hoàn toàn

• Vấn đề mất dấu vết audit

  • Vì đây là impersonation thực sự, dấu vết audit về ai đã thực hiện hành động thực tế sẽ biến mất
  • Vì vậy bắt buộc phải đi kèm cơ chế logging bên ngoài để ghi lại ai, khi nào, vì lý do gì đã khởi tạo việc trao đổi; nếu không, việc xử lý sự cố sẽ tạo ra khoảng trống bảo mật

Quản lý chuyển đổi giao thức (Managing Protocol Transition)

• Trong môi trường vẫn còn hệ thống legacy và giao thức cũ, một kịch bản phổ biến là vận hành song song hai hệ thống trong lúc di chuyển từ xác thực SAML sang OpenID Connect (OIDC)
• Dịch vụ xác thực người dùng bằng SAML sẽ đổi SAML assertion thành OAuth 2.0 access token; authorization server xác thực SAML artifact đầu vào rồi phát hành access token tiêu chuẩn mà downstream có thể hiểu

• Tham số subject_token_type

  • Dùng để nhận diện định dạng của token đầu vào; RFC 8693 định nghĩa nhiều định danh loại token khác nhau
    • SAML 2.0 assertion: urn:ietf:params:oauth:token-type:saml2
    • JWT token: urn:ietf:params:oauth:token-type:jwt
  • Authorization server có thể chấp nhận token từ các họ giao thức khác nhau và chuẩn hóa chúng thành định dạng nhất quán cho dịch vụ hiện đại
• Đây là mẫu thường xuất hiện khi hai tổ chức có các stack ID khác nhau do sáp nhập hoặc mua bán doanh nghiệp cần tương tác với nhau trước khi hoàn tất migration; người dùng vẫn xác thực theo cách cũ, còn hệ thống chuyển đổi credential sang dạng mà dịch vụ tiêu thụ yêu cầu

Chuỗi gọi dịch vụ (Chaining Service Calls)

• Trong kiến trúc microservices, sau khi Service A xử lý yêu cầu của người dùng rồi phải gọi Service B thay mặt người dùng, và tiếp đó Service B lại phải gọi Service C, câu hỏi cốt lõi là mỗi dịch vụ sẽ dùng credential nào cho lần gọi tiếp theo

• Tùy chọn 1 — dùng credential của chính dịch vụ

  • Service A bỏ qua ngữ cảnh người dùng và gọi Service B bằng client credential của riêng mình; phù hợp với các lời gọi giữa dịch vụ với nhau không cần ngữ cảnh người dùng như xử lý batch, kiểm tra trạng thái hệ thống hoặc đồng bộ dữ liệu
  • Khi có liên quan đến người dùng, Service B sẽ không thể ép buộc authorization ở cấp người dùng — nó không biết yêu cầu đến từ người dùng nào nên không thể kiểm tra quyền truy cập; ngữ cảnh bảo mật bị mất

• Tùy chọn 2 — dịch vụ impersonate người dùng

  • Service A chuyển nguyên token gốc của người dùng sang Service B hoặc đổi nó thành token không thể phân biệt với người dùng; Service B xem đây là yêu cầu do người dùng gửi và áp dụng authorization ở cấp người dùng
  • Service B không thể phân biệt hành động trực tiếp của người dùng với hành động do Service A thực hiện thay mặt; nếu Service A bị xâm phạm, nó có thể thực hiện mọi lời gọi trong phạm vi quyền của người dùng và không thể áp dụng mức độ tin cậy khác nhau cho yêu cầu trực tiếp và yêu cầu qua proxy — bảo toàn ngữ cảnh người dùng nhưng làm mất ngữ cảnh dịch vụ

• Tùy chọn 3 — hành động thay mặt người dùng (Delegation)

  • Service A đổi token của người dùng thành token mới nhận diện cả người dùng (subject) và Service A (actor); claim act trong token kết quả truyền đạt rằng “yêu cầu liên quan đến User X, do Service A thực hiện”
  • Đây là mô hình delegation mà RFC 8693 chủ yếu được thiết kế để hỗ trợ; Service B có thể đưa ra quyết định authorization tinh vi — nếu Service A cố thực hiện hành động mà người dùng không cho phép, yêu cầu sẽ thất bại
  • Claim act có thể được lồng (nestable); khi Service B gọi Service C, chuỗi delegation được mở rộng và cung cấp dấu vết audit đầy đủ
  • Đánh đổi là độ phức tạp — mỗi hop đều cần token exchange, làm tăng độ trễ và yêu cầu mỗi dịch vụ phải được đăng ký như một client với authorization server; tuy nhiên trong các kiến trúc coi trọng bảo mật và audit, đây là lựa chọn đúng nguyên tắc

Token Exchange và federation ID

• Khi dịch vụ đi qua nhiều security domain khác nhau (ví dụ: dịch vụ do tổ chức bên thứ ba cung cấp), kịch bản chuỗi sẽ phức tạp hơn nhiều
  • Service A giữ token để truy cập Service B thay mặt người dùng trong security domain của MyCompany
  • Service B cần gọi Service C được bảo vệ trong domain của External Provider, và vì vậy cần một access token phù hợp
• Token do authorization server của MyCompany phát hành không có ý nghĩa trong domain của External Provider — token do một authorization server phát hành không tự động được server khác chấp nhận, và ranh giới tin cậy tồn tại để giới hạn blast radius

• Giới hạn của cấu hình federation

  • Authorization server của External Provider phải được cấu hình để chấp nhận token từ domain MyCompany như subject token hợp lệ; điều này đòi hỏi thiết lập tin cậy trước, trao đổi metadata, xác thực chứng chỉ, cấu hình trực tiếp và ánh xạ danh tính xuyên domain
  • Khi số lượng domain tăng lên (tích hợp enterprise, hệ sinh thái SaaS, multi-cloud), ma trận quan hệ tin cậy song phương trở nên không thể quản lý nổi

• Cross App Access và Identity Chaining

  • Để giải quyết vấn đề mở rộng này, Cross App Access (XAA) triển khai Identity Assertion JWT Authorization Grant và đưa enterprise IdP vào làm bên trung gian cho trao đổi xuyên domain
  • Cách tiếp cận này tận dụng nhận định rằng IdP đã biết quan hệ giữa hai ứng dụng và người dùng; thay vì mọi cặp domain đều phải thiết lập tin cậy song phương, quyết định truy cập được tập trung về IdP

  • 4 bên tham gia trong luồng XAA

    • Requesting App: ứng dụng trong domain MyCompany (hoặc AI agent) cần truy cập tài nguyên ở domain khác
    • Enterprise IdP: nhà cung cấp ID của domain MyCompany, nơi xác thực nhân viên và quản lý chính sách cross-app
    • Resource App: ứng dụng sở hữu API được bảo vệ trong domain của External Provider
    • Resource Authorization Server: authorization server phát hành access token cho API được bảo vệ của Resource App

  • Luồng XAA từng bước

    • Nhân viên đăng nhập vào Requesting App qua SSO và nhận ID token từ IdP
    • Requesting App gửi lại ID token đó cho IdP để yêu cầu một identity assertion xuyên domain (ID-JAG, một JWT đặc biệt có scope cho cross-app)
    • IdP kiểm tra chính sách XAA — xác định xem có được phép truy cập Resource App thay mặt người dùng này hay không; nếu được phép thì trả về ID-JAG
    • Requesting App trình ID-JAG cho authorization server của Resource App
    • Authorization server của Resource App dùng khóa công khai của IdP qua OIDC discovery để xác thực ID-JAG rồi phát hành access token
    • Requesting App gọi API của Resource App bằng access token đó
  • Khác biệt mang tính quyết định so với token exchange thông thường là ở bước 3, nơi IdP thực thi quyết định chính sách — quản trị viên cấu hình rõ ràng ứng dụng nào được phép chạm tới tài nguyên nào, giúp IT có khả năng quan sát và kiểm soát, đồng thời người dùng không phải lặp lại luồng consent
  • Identity Chaining là mẫu rộng hơn, trong đó identity assertion của người dùng chảy theo cách chuẩn hóa từ lần xác thực ban đầu đến mọi dịch vụ downstream; XAA là một cách triển khai dựa trên các primitive của OAuth
  • Điều này đặc biệt phù hợp với các kịch bản AI agent nơi một yêu cầu đơn lẻ của người dùng có thể kích hoạt lời gọi dịch vụ tới nhiều nhà cung cấp bên thứ ba

Token Exchange và Auth0

• Auth0 triển khai token exchange bằng các cơ chế xử lý những điểm khác nhau trên phổ trường hợp sử dụng đã nêu ở trên

• Custom Token Exchange

  • Triển khai RFC 8693 tại endpoint /oauth/token của Auth0, cung cấp cho developer quyền kiểm soát hoàn toàn đối với logic xác thực
  • Định nghĩa Token Exchange Profile để ánh xạ URI subject_token_type tới một Action tùy chỉnh; khi có yêu cầu đến, Auth0 gọi mã Action để xác thực token, áp dụng quy tắc authorization và liên kết người dùng trong tenant
  • Vì Auth0 coi subject_token là một chuỗi opaque, nó có thể chấp nhận bất kỳ định dạng nào như JWT từ IdP khác, SAML assertion legacy, hoặc token độc quyền của API đối tác — đây là cơ chế cho chuyển đổi giao thức và federation tùy biến

• Token Vault

  • Dành cho các kịch bản AI agent phải gọi API bên thứ ba thay mặt người dùng trên nhiều nhà cung cấp, bổ sung khả năng lưu trữ an toàn và quản lý vòng đời tự động cho token exchange
  • Sau khi xác thực, người dùng liên kết các tài khoản như Google, GitHub, Slack, Microsoft; Token Vault lưu trữ token an toàn và tự động xử lý refresh, còn AI agent dùng token exchange để lấy access token hợp lệ từ kho
  • Token kết quả chứa claim act nhận diện AI agent — tạo ra dấu vết audit cho biết agent nào đã truy cập dịch vụ nào thay mặt người dùng nào; đây là yếu tố thiết yếu cho compliance trong doanh nghiệp, nơi cần biết điều gì đã kích hoạt tự động hóa

• On-Behalf-Of (OBO) Token Exchange

  • Trực tiếp triển khai mẫu delegation cho các kịch bản chuỗi dịch vụ; dịch vụ tầng trung gian đổi token người dùng đầu vào sang token mới có scope cho API downstream và tự thêm mình vào chuỗi delegation qua claim act
  • Hỗ trợ tối đa 5 cấp lồng chuỗi delegation, mỗi token mang các claim sub (giữ danh tính người dùng), aud (scope theo dịch vụ đích) và act lồng nhau (ghi lại chuỗi dịch vụ đã tham gia)

• Cross App Access (XAA)

  • Dành cho kịch bản federation ID nơi ứng dụng yêu cầu phải gọi resource API được bảo vệ bởi authorization server khác; triển khai phần mở rộng OAuth Identity Assertion Authorization Grant
  • Auth0 đóng vai trò Resource Authorization Server — Requesting App gửi ID token của người dùng tới IdP như Okta để nhận ID-JAG, và IdP chỉ phát hành assertion nếu quản trị viên đã cấu hình kết nối cross-app trong Admin Console
  • Requesting App trình ID-JAG cho Auth0, Auth0 xác thực qua OIDC discovery rồi phát hành access token có scope, mang lại cho IT khả năng quan sát tập trung đối với việc chia sẻ dữ liệu giữa các ứng dụng

Chọn cách tiếp cận phù hợp

• Token exchange không phải một giải pháp đơn lẻ mà là một tập hợp mẫu; lựa chọn phụ thuộc vào ngữ cảnh cần bảo toàn và ranh giới tin cậy cần vượt qua
  • Impersonation của quản trị viên: khi cần nhìn đúng màn hình mà người dùng đang thấy để xử lý sự cố
  • Chuyển đổi giao thức: khi cần một cây cầu nối giữa hệ thống ID legacy và hiện đại trong quá trình migration
  • Delegation: khi chuỗi dịch vụ cần ngữ cảnh người dùng cùng khả năng audit đầy đủ
  • Cross App Access / Identity Chaining: khi delegation phải đi qua nhiều security domain
  • Token Vault: khi AI agent cần quyền truy cập được quản lý tới API bên thứ ba thay mặt người dùng
• AI agent điều phối công việc thay mặt người dùng trên nhiều dịch vụ và nhà cung cấp về bản chất là chuỗi delegation, và cơ chế token exchange chính là nền tảng bảo mật giúp chuỗi đó có thể audit được, được cấp quyền đúng mức và được giới hạn theo ý định của người dùng