OAuth 2.0 Token Exchange: Membatasi Akses Antar-Layanan dengan Token yang Tepat

Dalam aplikasi modern, satu permintaan sering melewati beberapa komponen: API gateway, layanan pesanan, pembayaran, dan pengiriman. Token akses yang diterima oleh satu layanan belum tentu cocok untuk layanan berikutnya. Meneruskan token yang sama ke semua komponen dapat menyebabkan kegagalan validasi atau memberikan hak akses yang terlalu luas. OAuth 2.0 Token Exchange memungkinkan klien menukar token yang dimilikinya dengan token lain yang sesuai untuk konteks dan layanan tujuan.

Mekanisme ini didefinisikan dalam RFC 8693. RFC tersebut menjelaskan protokol pertukaran token melalui authorization server yang menjalankan fungsi Security Token Service (STS). Dukungan Token Exchange tidak otomatis tersedia di setiap implementasi OAuth 2.0; penyedia identitas harus mendukungnya dan administrator perlu menetapkan kebijakan yang sesuai.

Mengapa token perlu ditukar?

Bayangkan layanan pesanan menerima access token yang ditujukan untuk API pesanan. Saat layanan itu perlu menghubungi API pengiriman, token awal mungkin memiliki audience yang tidak cocok. Mengirimkannya begitu saja dapat ditolak oleh layanan tujuan. Lebih buruk lagi, jika token awal memiliki izin luas, kebocorannya bisa memberi akses ke lebih banyak sumber daya daripada yang diperlukan.

Dengan Token Exchange, layanan dapat meminta token baru yang ditujukan khusus untuk API pengiriman dan hanya membawa izin yang dibutuhkan. Authorization server memutuskan apakah pertukaran diizinkan berdasarkan token sumber, identitas klien, tujuan, serta kebijakan keamanan. Pendekatan ini mendukung prinsip least privilege: setiap komponen hanya memperoleh akses minimum untuk menjalankan tugasnya.

Bagaimana alur Token Exchange bekerja?

1. Klien memiliki token sumber. Token ini dapat mewakili pengguna atau subjek lain dan harus berasal dari sumber yang dipercaya.
2. Klien mengirim permintaan ke token endpoint. Permintaan menggunakan grant type urn:ietf:params:oauth:grant-type:token-exchange dan biasanya menyertakan subject_token serta subject_token_type.
3. Authorization server memvalidasi permintaan. Server memeriksa token sumber, klien peminta, hak untuk melakukan pertukaran, dan tujuan atau batasan yang diminta. Parameter tambahan seperti audience, resource, scope, atau requested_token_type digunakan sesuai dukungan implementasi dan kebijakan server.
4. Server menerbitkan token keluaran jika diizinkan. Token baru membawa klaim dan hak akses yang ditetapkan server, bukan sekadar salinan token sumber.
5. Layanan tujuan memvalidasi token baru. Layanan tetap harus memeriksa penerbit, masa berlaku, audience, tanda tangan atau mekanisme validasi yang sesuai, serta izin yang dibawanya.

Nama parameter dan nilai yang diizinkan mengikuti RFC 8693 serta implementasi penyedia identitas. Jangan menganggap semua server mendukung setiap parameter atau mengembalikan jenis token yang sama.

Delegasi dan impersonasi

RFC 8693 menjelaskan dua semantik yang perlu dibedakan. Delegasi berarti suatu layanan bertindak atas nama pengguna, sementara identitas layanan yang melakukan tindakan tetap dapat dibedakan. Jika token dan sistem mendukung informasi aktor, jejak audit dapat menunjukkan pengguna yang diwakili sekaligus layanan yang menjalankan permintaan.

Impersonasi membuat token keluaran diperlakukan sebagai subjek yang diwakili dalam konteks hak yang diberikan. Model ini lebih sensitif karena tindakan layanan dapat tampak seperti tindakan pengguna apabila identitas aktor tidak dipertahankan atau tidak dicatat secara memadai. Pilih model berdasarkan kebutuhan aplikasi, dukungan penyedia identitas, dan persyaratan audit. Jangan mengasumsikan klaim token akan identik pada semua implementasi.

Contoh penggunaan

• Microservices: layanan pesanan memperoleh token terbatas untuk memanggil layanan pengiriman tanpa membagikan token yang ditujukan untuk API pesanan.
• API gateway: gateway menukar token masuk dengan token yang cocok untuk backend tertentu, berdasarkan kebijakan yang ditetapkan.
• Integrasi antarsistem: authorization server menjadi titik kontrol untuk memvalidasi kepercayaan, memetakan klaim, dan menerbitkan token bagi sistem tujuan.
• Tugas otomatis atas nama pengguna: layanan latar belakang memperoleh akses terbatas untuk menyelesaikan pekerjaan yang diizinkan, dengan identitas aktor dicatat jika didukung desainnya.

Token Exchange bukan pengganti seluruh mekanisme OAuth 2.0 dan tidak selalu diperlukan. Jika token yang ada sudah ditujukan kepada layanan yang benar serta memiliki izin yang tepat, pertukaran tambahan dapat menambah latensi, kompleksitas konfigurasi, dan titik kegagalan. Gunakan mekanisme ini ketika memang ada kebutuhan untuk mengubah konteks, tujuan, atau hak akses token.

Praktik keamanan yang penting

Batasi audience dan scope

Terbitkan token untuk layanan atau resource yang spesifik dan berikan scope minimum yang dibutuhkan. Jangan mengandalkan parameter yang diminta klien sebagai bukti bahwa akses tersebut boleh diberikan; authorization server harus menerapkan kebijakannya sendiri.

Validasi token sumber dan klien

Periksa penerbit, masa berlaku, integritas, jenis token, serta hak klien untuk melakukan pertukaran. Tolak token dari penerbit atau tipe yang tidak dipercaya, dan jangan mengizinkan klien menukar token untuk tujuan di luar kewenangannya.

Jangan menaikkan hak secara tidak sengaja

Token keluaran tidak boleh memperoleh izin yang lebih tinggi hanya karena klien memintanya. Terapkan aturan yang jelas untuk pemetaan klaim, audience, scope, dan hubungan kepercayaan. Uji juga permintaan yang mencoba menggunakan token pengguna lain atau meminta akses ke layanan yang tidak terkait.

Lindungi token dan catatan audit

Perlakukan token sebagai rahasia: kirim melalui TLS, jangan menaruh token lengkap dalam log, tiket dukungan, URL, atau analitik, dan simpan kredensial klien dalam penyimpanan rahasia yang sesuai. Catat hasil pertukaran, identitas klien, tujuan, serta alasan penolakan tanpa merekam nilai token. Terapkan rotasi kredensial dan prosedur pencabutan sesuai risiko.

Uji kegagalan dan pantau penggunaan

Uji token kedaluwarsa, audience yang salah, scope berlebihan, klien yang tidak berwenang, dan token dari penerbit yang tidak dipercaya. Pantau lonjakan permintaan, penolakan, serta pola pertukaran yang tidak biasa. Pastikan kegagalan pertukaran ditangani dengan aman dan tidak membuat aplikasi beralih ke token yang lebih luas sebagai jalan pintas.

Kesalahan yang perlu dihindari

• Menganggap Token Exchange didukung oleh semua server OAuth 2.0.
• Meneruskan token sumber ke semua layanan tanpa memeriksa audience dan scope.
• Menganggap token keluaran otomatis aman tanpa validasi oleh layanan penerima.
• Menyamakan delegasi dengan impersonasi dan mengabaikan jejak audit aktor.
• Mencatat token lengkap dalam log atau memberikan hak lebih luas daripada kebutuhan layanan.

Kesimpulan

OAuth 2.0 Token Exchange (RFC 8693) membantu aplikasi memperoleh token yang sesuai untuk layanan, resource, atau konteks kepercayaan tertentu. Manfaat utamanya adalah kontrol akses yang lebih terarah ketika satu permintaan melewati banyak layanan. Keamanan tetap bergantung pada validasi token sumber, kebijakan penerbitan yang ketat, audience dan scope yang terbatas, validasi token keluaran, serta pencatatan audit yang tidak membocorkan rahasia. Terapkan pertukaran token hanya ketika kebutuhan arsitektur membenarkannya dan pastikan implementasi penyedia identitas telah diuji.