OAuth 2.0 Token Exchange के कई रूप

• एक security token को दूसरे token में बदलने का standard-based mechanism, जो RFC 8693 में परिभाषित OAuth 2.0 extension spec है
• authorization server को Security Token Service(STS) में बदलता है, ताकि वह client द्वारा भेजे गए token को validate करे और अलग context, target audience, और purpose के लिए नया token issue करे
• इसका संचालन मोटे तौर पर दो मोड में बंटता है: Impersonation और Delegation
• admin impersonation, protocol transition, service chaining, federation ID जैसे अलग-अलग use case में trade-off और security impact मौजूद हैं
• AI agent के बढ़ने के साथ, कई services और providers के बीच जाने वाले workflows मूलतः delegation chain बनते जा रहे हैं, इसलिए token exchange और भी महत्वपूर्ण हो गया है

---

Token Exchange क्या है

• client subject_token (ऐसा token जो request subject user/entity को दर्शाता है) भेजता है, और वैकल्पिक रूप से actor_token (exchange करने वाला पक्ष) भी भेज सकता है; बदले में target context के अनुरूप नया token मिलता है
• मौजूदा token को वैसे ही forward करना या नया token अलग से बनाना सहज लग सकता है, लेकिन दोनों तरीके गंभीर समस्याएँ पैदा कर सकते हैं; इन्हीं को हल करने के लिए यह spec बनाई गई

• दो बुनियादी operating mode

  • Impersonation: request करने वाले पक्ष को ऐसा token मिलता है जिसे मूल subject से अलग नहीं पहचाना जा सकता; downstream service यह नहीं समझ पाती कि request असली user ने की है या किसी ने उसकी जगह
  • Delegation: दोनों पक्षों की identity सुरक्षित रहती है; नए token में शामिल act (actor) claim के जरिए downstream service user और behalf पर काम करने वाले actor दोनों को पहचान सकती है
  • impersonation शक्तिशाली है लेकिन opaque, delegation पर कुछ constraints हैं लेकिन वह audit-friendly है — यही चुनाव security posture और traceability तय करता है

Administrative Impersonation

• जब customer dashboard में गलत data दिखने की समस्या diagnose करनी हो, तब support engineer को ग्राहक के समान permissions और data access के साथ वही screen देखनी पड़ सकती है
• admin अपने token को ग्राहक की identity दर्शाने वाले token में exchange करता है; नतीजे वाला token ग्राहक का sub claim, scope, और audience रखता है, इसलिए application के नज़रिए से request ग्राहक की लगती है
• इस मामले में request केवल subject_token (जिस user की जगह act करना है) का उपयोग करती है, actor_token नहीं देती — क्योंकि लक्ष्य पूर्ण impersonation है

• audit trail खोने की समस्या

  • क्योंकि यह वास्तविक impersonation है, इसलिए audit trail से यह गायब हो जाता है कि action वास्तव में किसने किया
  • इसलिए किसने, कब, और किस कारण से exchange शुरू किया, इसका रिकॉर्ड रखने वाला बाहरी logging mechanism साथ में होना ज़रूरी है; नहीं तो troubleshooting के नाम पर security gap बन सकता है

Protocol Transition को manage करना

• legacy system और पुराने protocol वाले environment में, SAML authentication से OpenID Connect(OIDC) पर migration करते समय दोनों system कुछ समय साथ चल सकते हैं
• SAML से user authenticate करने वाली service SAML assertion को OAuth 2.0 access token में exchange करती है; authorization server आने वाले SAML artifact को validate करके downstream के लिए समझने योग्य standard access token issue करता है

• subject_token_type parameter

  • यह incoming token का format पहचानता है; RFC 8693 कई token type identifier परिभाषित करता है
    • SAML 2.0 assertion: urn:ietf:params:oauth:token-type:saml2
    • JWT token: urn:ietf:params:oauth:token-type:jwt
  • authorization server अलग-अलग protocol family के token लेकर उन्हें modern services के लिए एक consistent format में normalize कर सकता है
• यह pattern अक्सर तब दिखता है जब merger या acquisition के बाद अलग-अलग ID stack वाली दो organizations को पूरी migration से पहले interoperable होना पड़ता है; user पुराने तरीके से authenticate करता है और system credentials को target service की ज़रूरत के अनुसार बदल देता है

Service Call Chaining

• microservice architecture में, जब Service A user request handle करने के बाद user की ओर से Service B को और फिर Service B को Service C को call करना हो, तब मुख्य सवाल होता है कि हर service अगले call के लिए कौन-से credentials इस्तेमाल करे

• Option 1 — service के अपने credentials का उपयोग

  • Service A user context को ignore करके अपने client credentials से Service B को call करता है; यह batch processing, system health check, data sync जैसी service-to-service calls के लिए ठीक है जहाँ user context की ज़रूरत नहीं होती
  • लेकिन user शामिल हो तो Service B user-level authorization enforce नहीं कर सकता — उसे पता ही नहीं चलेगा कि request किस user ने शुरू की, इसलिए access check नहीं हो पाएगा; security context खो जाता है

• Option 2 — service user का impersonation करे

  • Service A user का original token सीधे Service B को forward करता है, या उसे ऐसे token में exchange करता है जो user से अलग नहीं दिखता; Service B इसे user-originated request मानकर user-level authorization लागू करता है
  • Service B user की direct action और Service A की proxy action में फर्क नहीं कर सकता; अगर Service A compromise हो जाए तो वह user की permissions के भीतर सब कुछ call कर सकता है, और direct/proxy requests पर अलग trust level लागू नहीं किया जा सकता — user context बचता है, लेकिन service context खो जाता है

• Option 3 — user की ओर से act करना (Delegation)

  • Service A user token को user(subject) और Service A(actor) दोनों की पहचान वाले नए token में exchange करता है; नतीजे वाले token का act claim बताता है: "यह request User X से संबंधित है, लेकिन इसे Service A चला रही है"
  • यही delegation model है जिसे RFC 8693 मुख्य रूप से support करने के लिए डिज़ाइन किया गया; Service B ज्यादा सूक्ष्म authorization decision ले सकता है — यदि Service A ऐसा action करने की कोशिश करे जिसकी user ने अनुमति नहीं दी, तो request fail हो जाएगी
  • act claim nestable हो सकता है; Service B जब Service C को call करता है तो delegation chain और आगे बढ़ती है, जिससे पूरा audit trail मिलता है
  • trade-off है complexity — हर hop पर token exchange चाहिए, latency बढ़ती है, और हर service को authorization server पर client के रूप में register होना पड़ता है; फिर भी जहाँ security और audit महत्वपूर्ण हों, वहाँ यह principled choice है

Token Exchange और Federation ID

• जब services security domain के पार जाती हैं, जैसे किसी third-party organization की service, तब chain scenario काफी जटिल हो जाता है
  • Service A के पास MyCompany security domain में user की ओर से Service B को access करने वाला token है
  • Service B को External Provider domain में सुरक्षित Service C को call करना है, जिसके लिए अलग access token चाहिए
• MyCompany authorization server द्वारा issue किया गया token External Provider domain में अर्थहीन है — एक authorization server का token दूसरा server अपने-आप स्वीकार नहीं करता; trust boundary damage के blast radius को सीमित करने के लिए होती है

• federation setup की सीमाएँ

  • External Provider authorization server को इस तरह configure करना पड़ता है कि वह MyCompany domain के token को valid subject token माने; इसके लिए metadata exchange, certificate validation, direct configuration के जरिए prior trust और domain के बीच identity mapping चाहिए
  • domains बढ़ने पर, जैसे enterprise integration, SaaS ecosystem, या multi-cloud में, pairwise trust relationship का matrix manage करना लगभग असंभव हो जाता है

• Cross App Access और Identity Chaining

  • इस scaling problem को हल करने के लिए Cross App Access(XAA), Identity Assertion JWT Authorization Grant को implement करता है और cross-domain exchange में enterprise IdP को mediator बनाता है
  • इसका insight यह है कि IdP पहले से दोनों applications और user के रिश्ते को जानता है; इसलिए हर domain pair के बीच bilateral trust बनाने के बजाय access decision को IdP पर केंद्रीकृत किया जा सकता है

  • XAA flow के 4 पक्ष

    • Requesting App: MyCompany domain का application (या AI agent) जिसे दूसरे domain के resource तक पहुँचना है
    • Enterprise IdP: MyCompany domain का identity provider, जो employee को authenticate करता है और cross-app policy manage करता है
    • Resource App: External Provider domain का application, जिसके पास protected API है
    • Resource Authorization Server: authorization server जो Resource App की protected API के लिए access token issue करता है

  • XAA step-by-step flow

    • employee SSO से Requesting App में login करता है और IdP से ID token प्राप्त करता है
    • Requesting App उसी ID token को वापस IdP को भेजकर cross-domain identity assertion माँगता है — ID-JAG, यानी cross-app use के लिए scoped विशेष JWT
    • IdP XAA policy जाँचता है — क्या इस user की ओर से Resource App access की अनुमति है; अनुमति मिलने पर ID-JAG लौटाता है
    • Requesting App ID-JAG को Resource App authorization server के सामने प्रस्तुत करता है
    • Resource App authorization server OIDC discovery के जरिए IdP public key से ID-JAG validate करता है और access token issue करता है
    • Requesting App उसी access token से Resource App API को call करता है
  • सामान्य token exchange से निर्णायक अंतर तीसरे step में है, जहाँ IdP policy decision enforce करता है — admin स्पष्ट रूप से configure करते हैं कि कौन-सा app किन resources तक पहुँच सकता है; इससे IT को visibility और control मिलता है और user बार-बार consent flow से बचता है
  • Identity Chaining एक व्यापक pattern है, जिसमें user identity assertion शुरुआती authentication से लेकर सभी downstream services तक standard तरीके से बहती है; XAA, OAuth primitive पर आधारित इसका एक implementation है
  • यह खास तौर पर AI agent scenario में प्रासंगिक है, जहाँ एक user request कई third-party providers की services को trigger कर सकती है

Token Exchange और Auth0

• Auth0 token exchange को अलग-अलग mechanisms के रूप में implement करता है, जो ऊपर बताए गए spectrum के विभिन्न हिस्सों को address करते हैं

• Custom Token Exchange

  • Auth0 के /oauth/token endpoint पर RFC 8693 का implementation, जो validation logic पर developer को पूरा control देता है
  • Token Exchange Profile परिभाषित करता है, जो subject_token_type URI को custom Action से map करता है; request आने पर Auth0 Action code चलाता है ताकि token validate हो, authorization rules enforce हों, और tenant के भीतर user connection हो
  • क्योंकि Auth0 subject_token को opaque string की तरह treat करता है, इसलिए वह किसी भी format को स्वीकार कर सकता है — दूसरे IdP का JWT, legacy SAML assertion, partner API का proprietary token आदि; यह protocol transition और custom federation के लिए mechanism है

• Token Vault

  • कई providers में user की ओर से third-party API call करने वाले AI agent scenario के लिए, token exchange में secure storage और automatic lifecycle management जोड़ता है
  • user authentication के बाद account (Google, GitHub, Slack, Microsoft आदि) connect करता है; Token Vault token को सुरक्षित रखता है, refresh अपने-आप संभालता है, और AI agent token exchange के जरिए vault से valid access token प्राप्त करता है
  • result token में AI agent को पहचानने वाला act claim शामिल होता है — इससे audit trail बनता है कि किस agent ने किस user की ओर से किस service को access किया; enterprise compliance के लिए यह ज़रूरी है, क्योंकि जानना होता है कि automation किसने trigger की

• On-Behalf-Of (OBO) Token Exchange

  • service chain scenario के लिए delegation pattern को सीधे implement करता है; middle-tier service incoming user token को downstream API के लिए scoped नए token में exchange करती है और act claim के जरिए खुद को delegation chain में जोड़ती है
  • अधिकतम 5-level delegation chain nesting support करता है; हर token में sub (user identity बनी रहती है), aud (target service scope), और nested act (शामिल service chain का रिकॉर्ड) claims होते हैं

• Cross App Access (XAA)

  • federation ID scenario के लिए, जहाँ requesting application को किसी दूसरे authorization server द्वारा protected resource API call करनी हो; यह Identity Assertion Authorization Grant OAuth extension का implementation है
  • Auth0 यहाँ Resource Authorization Server की भूमिका निभाता है — Requesting App user ID token को Okta जैसे IdP को भेजता है और ID-JAG पाता है; IdP assertion तभी issue करता है जब admin ने Admin Console में cross-app connection configure किया हो
  • Requesting App ID-JAG को Auth0 के सामने प्रस्तुत करता है; Auth0 OIDC discovery के जरिए उसे validate करके scoped access token issue करता है, जिससे IT को cross-app data sharing पर centralized visibility मिलती है

सही approach कैसे चुनें

• token exchange कोई एकल solution नहीं, बल्कि patterns का समूह है; कौन-सा context सुरक्षित रखना है और कौन-सी trust boundary पार करनी है, इसी पर चुनाव निर्भर करता है
  • Administrative Impersonation: जब troubleshooting के लिए user जो देखता है, वही ठीक-ठीक देखना हो
  • Protocol Transition: जब migration के दौरान legacy और modern ID systems के बीच bridge चाहिए
  • Delegation: जब service chain को user context के साथ पूरी auditability चाहिए
  • Cross App Access / Identity Chaining: जब delegation कई security domains में फैला हो
  • Token Vault: जब AI agent को user की ओर से third-party APIs तक managed access चाहिए
• कई services और providers में user की ओर से tasks orchestrate करने वाले AI agent मूलतः delegation chain ही हैं; token exchange mechanism वही security foundation देता है जो इस chain को auditable, authorized, और user intent के अनुरूप scoped बनाता है