Berbagai Wajah OAuth 2.0 Token Exchange

• Mekanisme berbasis standar untuk mengubah satu token keamanan menjadi token lain, didefinisikan dalam spesifikasi ekstensi OAuth 2.0 RFC 8693
• Mengubah authorization server menjadi Security Token Service (STS), yang memverifikasi token yang dikirim klien lalu menerbitkan token baru yang sesuai untuk konteks, target (audience), dan tujuan yang berbeda
• Cara kerjanya secara garis besar terbagi menjadi dua mode: impersonation dan delegation
• Setiap use case yang berbeda seperti impersonation admin, transisi protokol, service chaining, dan federation ID memiliki trade-off serta dampak keamanan masing-masing
• Dengan meluasnya AI agent, pekerjaan yang melintasi banyak layanan dan penyedia pada dasarnya menjadi rantai delegasi, sehingga pentingnya token exchange makin besar

---

Apa itu Token Exchange

• Klien mengirim subject_token (token yang merepresentasikan pengguna/entitas yang menjadi subjek permintaan), dan secara opsional juga actor_token (pihak yang menjalankan pertukaran), lalu menerima token baru yang sesuai dengan konteks target
• Meneruskan token lama apa adanya atau membuat token baru dengan cara ad hoc tampak intuitif, tetapi keduanya menimbulkan masalah serius, sehingga spesifikasi ini dibuat untuk mengatasinya

• Dua mode operasi dasar

  • Impersonation: pihak yang meminta menerima token yang tidak dapat dibedakan dari subjek asli, sehingga layanan downstream tidak bisa membedakan apakah itu pengguna asli atau pihak yang menyamar
  • Delegation: identitas kedua pihak tetap dipertahankan, dan melalui claim act (actor) yang disertakan dalam token baru, layanan downstream dapat mengetahui baik pengguna maupun pelaksana yang bertindak atas namanya
  • Impersonation kuat tetapi tidak transparan, sedangkan delegation lebih terbatas namun dapat diaudit — pilihan ini menentukan postur keamanan dan kemampuan penelusuran

Impersonation Admin (Administrative Impersonation)

• Saat mendiagnosis masalah ketika dashboard pelanggan menampilkan data yang salah, engineer dukungan perlu melihat layar persis seperti yang dilihat pelanggan, dengan hak dan akses data yang sama
• Admin menukar token miliknya menjadi token yang merepresentasikan identitas pelanggan; token hasilnya memuat claim sub, scope, dan audience milik pelanggan, sehingga dari sudut pandang aplikasi permintaan itu dikenali sebagai permintaan dari pelanggan
• Dalam kasus ini, permintaan hanya memakai subject_token (pengguna yang akan disamar) dan tidak menyertakan actor_token — karena tujuannya adalah impersonation penuh

• Masalah hilangnya audit trail

  • Karena ini benar-benar impersonation, audit trail tentang siapa yang sebenarnya melakukan tindakan tersebut menjadi hilang
  • Karena itu, harus selalu disertai mekanisme logging eksternal yang mencatat siapa, kapan, dan untuk alasan apa pertukaran dimulai; jika tidak, pemecahan masalah bisa membuka celah keamanan

Mengelola Transisi Protokol (Managing Protocol Transition)

• Dalam lingkungan yang masih memiliki sistem legacy dan protokol lama, ada skenario menjalankan dua sistem sekaligus sambil bermigrasi dari autentikasi SAML ke OpenID Connect (OIDC)
• Layanan yang mengautentikasi pengguna dengan SAML menukar SAML assertion menjadi access token OAuth 2.0; authorization server memverifikasi artefak SAML yang masuk lalu menerbitkan access token standar yang dipahami sistem downstream

• Parameter subject_token_type

  • Mengidentifikasi format token yang masuk; RFC 8693 mendefinisikan beberapa identifier tipe token
    • SAML 2.0 assertion: urn:ietf:params:oauth:token-type:saml2
    • Token JWT: urn:ietf:params:oauth:token-type:jwt
  • Ini memungkinkan authorization server menerima token dari keluarga protokol yang berbeda dan menormalisasikannya ke format yang konsisten untuk layanan modern
• Ini adalah pola yang muncul saat dua organisasi dengan stack ID berbeda harus saling interoperasi sebelum migrasi penuh, misalnya akibat merger atau akuisisi; pengguna tetap login dengan cara lama, sementara sistem mengubah kredensial ke bentuk yang dibutuhkan layanan konsumen

Chaining Panggilan Layanan (Chaining Service Calls)

• Dalam arsitektur microservices, setelah Service A memproses permintaan pengguna lalu harus memanggil Service B atas nama pengguna, dan Service B kembali harus memanggil Service C, pertanyaan kuncinya adalah kredensial apa yang harus dipakai tiap layanan untuk panggilan berikutnya

• Opsi 1 — Gunakan kredensial milik layanan sendiri

  • Service A mengabaikan konteks pengguna dan memanggil Service B dengan client credentials miliknya sendiri; cocok untuk panggilan antar-layanan yang tidak memerlukan konteks pengguna seperti batch processing, pemeriksaan status sistem, atau sinkronisasi data
  • Jika pengguna sebenarnya terlibat, Service B tidak bisa memaksakan otorisasi tingkat pengguna — tidak tahu pengguna mana yang meminta, sehingga tidak dapat memeriksa hak akses; konteks keamanan hilang

• Opsi 2 — Layanan meng-impersonate pengguna

  • Service A meneruskan token asli pengguna apa adanya ke Service B atau menukarnya dengan token yang tidak dapat dibedakan dari pengguna; Service B melihatnya sebagai permintaan yang berasal dari pengguna dan menerapkan otorisasi tingkat pengguna
  • Service B tidak dapat membedakan tindakan langsung pengguna dari tindakan perwakilan oleh Service A; jika Service A disusupi, ia dapat melakukan semua panggilan dalam batas hak pengguna dan tidak mungkin menerapkan tingkat kepercayaan berbeda untuk permintaan langsung vs proxy — konteks pengguna terjaga, tetapi konteks layanan hilang

• Opsi 3 — Bertindak atas nama pengguna (Delegation)

  • Service A menukar token pengguna menjadi token baru yang mengidentifikasi baik pengguna (subject) maupun Service A (actor); claim act pada token hasil menyampaikan "permintaan terkait User X, dijalankan oleh Service A"
  • Ini adalah model delegation yang terutama ingin didukung oleh RFC 8693, dan memungkinkan Service B membuat keputusan otorisasi yang lebih canggih — jika Service A mencoba tindakan yang tidak diizinkan pengguna, permintaan akan gagal
  • Claim act dapat dinest, jadi ketika Service B memanggil Service C, rantai delegasi dapat diperluas dan menyediakan audit trail lengkap
  • Trade-off-nya adalah kompleksitas — setiap hop memerlukan token exchange sehingga menambah latensi, dan setiap layanan harus terdaftar sebagai klien di authorization server; namun untuk arsitektur yang mengutamakan keamanan dan audit, ini adalah pilihan yang paling berprinsip

Token Exchange dan Federation ID

• Saat layanan melintasi domain keamanan yang berbeda, misalnya layanan yang disediakan organisasi pihak ketiga, skenario chaining menjadi jauh lebih rumit
  • Service A memegang token untuk mengakses Service B atas nama pengguna di dalam domain keamanan MyCompany
  • Service B harus memanggil Service C yang dilindungi di domain External Provider, dan membutuhkan access token untuk itu
• Token yang diterbitkan authorization server MyCompany tidak bermakna di domain External Provider — token yang diterbitkan satu authorization server tidak otomatis diterima server lain, dan trust boundary ada untuk membatasi blast radius

• Batasan konfigurasi federation

  • Authorization server milik External Provider harus dikonfigurasi agar menerima token dari domain MyCompany sebagai subject token yang valid; ini memerlukan trust awal dan pemetaan identitas lintas domain melalui pertukaran metadata, verifikasi sertifikat, dan konfigurasi langsung
  • Semakin banyak domain yang terlibat — enterprise integration, ekosistem SaaS, multi-cloud — semakin tidak terkelolanya matriks hubungan trust bilateral

• Cross App Access dan Identity Chaining

  • Untuk mengatasi masalah skala ini, Cross App Access (XAA) mengimplementasikan Identity Assertion JWT Authorization Grant dan memperkenalkan enterprise IdP sebagai mediator untuk pertukaran lintas domain
  • Intinya adalah memanfaatkan fakta bahwa IdP sudah mengetahui hubungan antara kedua aplikasi dan pengguna, sehingga alih-alih setiap pasangan domain membangun trust bilateral, keputusan akses dipusatkan pada IdP

  • Empat pihak dalam alur XAA

    • Requesting App: aplikasi di domain MyCompany yang perlu mengakses resource di domain lain (atau AI agent)
    • Enterprise IdP: penyedia identitas domain MyCompany yang mengautentikasi karyawan dan mengelola kebijakan lintas aplikasi
    • Resource App: aplikasi yang memiliki API terlindungi di domain External Provider
    • Resource Authorization Server: authorization server yang menerbitkan access token untuk API terlindungi milik Resource App

  • Alur XAA langkah demi langkah

    • Karyawan login ke Requesting App lewat SSO dan memperoleh ID token dari IdP
    • Requesting App mengirim kembali ID token tersebut ke IdP untuk meminta assertion identitas lintas domain (ID-JAG, JWT khusus yang discoped untuk penggunaan lintas aplikasi)
    • IdP memeriksa kebijakan XAA — menentukan apakah akses ke Resource App diizinkan atas nama pengguna ini; jika diizinkan, IdP mengembalikan ID-JAG
    • Requesting App menyajikan ID-JAG ke authorization server milik Resource App
    • Authorization server milik Resource App memverifikasi ID-JAG menggunakan public key IdP melalui OIDC discovery lalu menerbitkan access token
    • Requesting App memanggil API Resource App menggunakan access token tersebut
  • Perbedaan paling penting dibanding token exchange biasa adalah bahwa pada langkah 3, IdP menegakkan keputusan kebijakan — admin secara eksplisit mengonfigurasi aplikasi mana yang boleh mencapai resource mana, memberi visibilitas dan kontrol kepada TI sekaligus membuat pengguna tidak perlu melalui alur consent berulang
  • Identity Chaining adalah pola yang lebih luas di mana assertion identitas pengguna mengalir secara terstandarisasi dari autentikasi awal hingga semua layanan downstream; XAA adalah salah satu implementasinya berbasis primitive OAuth
  • Ini sangat relevan dalam skenario AI agent di mana satu permintaan pengguna memicu panggilan layanan ke banyak penyedia pihak ketiga

Token Exchange dan Auth0

• Auth0 mengimplementasikan token exchange melalui beberapa mekanisme yang menangani titik berbeda dalam spektrum yang dibahas di atas

• Custom Token Exchange

  • Mengimplementasikan RFC 8693 pada endpoint /oauth/token milik Auth0, dengan kontrol penuh bagi developer atas logika verifikasi
  • Mendefinisikan Token Exchange Profile yang memetakan URI subject_token_type ke Action kustom; saat permintaan masuk, Auth0 memanggil kode Action untuk memverifikasi token, menegakkan aturan otorisasi, dan menghubungkan pengguna dalam tenant
  • Karena Auth0 memperlakukan subject_token sebagai string opak, format apa pun bisa diterima — JWT dari IdP lain, SAML assertion legacy, atau token proprietari dari API mitra — sehingga menjadi mekanisme untuk transisi protokol dan federation kustom

• Token Vault

  • Untuk skenario AI agent yang memanggil API pihak ketiga atas nama pengguna di banyak penyedia, menambahkan penyimpanan aman dan pengelolaan siklus hidup otomatis ke token exchange
  • Setelah pengguna diautentikasi, mereka menghubungkan akun (Google, GitHub, Slack, Microsoft, dll.); Token Vault menyimpan token dengan aman dan menangani refresh secara otomatis, lalu AI agent mengambil access token yang valid dari vault melalui token exchange
  • Token hasil menyertakan claim act yang mengidentifikasi AI agent — membentuk audit trail tentang agent mana yang mengakses layanan mana atas nama pengguna mana, hal yang penting untuk kepatuhan enterprise yang perlu mengetahui apa yang memicu otomatisasi

• On-Behalf-Of (OBO) Token Exchange

  • Secara langsung mengimplementasikan pola delegation untuk skenario service chain; layanan lapisan tengah menukar token pengguna yang masuk dengan token baru yang discoped untuk API downstream, sambil menambahkan dirinya ke rantai delegasi melalui claim act
  • Mendukung hingga 5 tingkat nested delegation chain, dan setiap token memiliki claim sub (menjaga identitas pengguna), aud (discoped ke layanan target), dan act bertingkat (mencatat rantai layanan yang terlibat)

• Cross App Access (XAA)

  • Untuk skenario federation ID ketika aplikasi peminta harus memanggil resource API yang dilindungi authorization server lain, mengimplementasikan ekstensi OAuth Identity Assertion Authorization Grant
  • Auth0 berperan sebagai Resource Authorization Server — Requesting App mengirim ID token pengguna ke IdP seperti Okta untuk menerima ID-JAG, dan IdP hanya menerbitkan assertion jika admin telah mengonfigurasi koneksi lintas aplikasi di Admin Console
  • Saat Requesting App menyajikan ID-JAG ke Auth0, Auth0 memverifikasinya melalui OIDC discovery lalu menerbitkan access token yang discoped, memberi TI visibilitas terpusat atas pembagian data lintas aplikasi

Memilih Pendekatan yang Tepat

• Token exchange bukan satu solusi tunggal, melainkan sekumpulan pola; pilihannya bergantung pada konteks apa yang harus dipertahankan dan trust boundary apa yang harus dilintasi
  • Impersonation admin: saat Anda harus melihat layar persis seperti yang dilihat pengguna untuk pemecahan masalah
  • Transisi protokol: saat Anda memerlukan jembatan antara sistem ID legacy dan modern selama migrasi
  • Delegation: saat service chain membutuhkan konteks pengguna dengan kemampuan audit penuh
  • Cross App Access / Identity Chaining: saat delegation harus melintasi banyak domain keamanan
  • Token Vault: saat AI agent memerlukan akses terkelola ke API pihak ketiga atas nama pengguna
• AI agent yang mengorkestrasi pekerjaan atas nama pengguna di banyak layanan dan penyedia pada dasarnya adalah rantai delegasi, dan mekanisme token exchange menjadi fondasi keamanan yang membuat rantai itu dapat diaudit, diotorisasi, dan discoped sesuai niat pengguna