Tentang kredensial API dan manajer kredensial
BERLAKU UNTUK: Semua tingkatAN API Management
Untuk membantu Anda mengelola akses ke API backend, instans API Management Anda menyertakan manajer kredensial. Gunakan pengelola kredensial untuk mengelola, menyimpan, dan mengontrol akses ke kredensial API dari instans API Management Anda.
Catatan
- Saat ini, Anda dapat menggunakan pengelola kredensial untuk mengonfigurasi dan mengelola koneksi (sebelumnya disebut otorisasi) untuk API OAuth 2.0 backend.
- Tidak ada perubahan yang melanggar yang diperkenalkan dengan manajer kredensial. Penyedia dan koneksi kredensial OAuth 2.0 menggunakan API otorisasi API Management dan penyedia sumber daya yang ada.
Catatan
Saat ini, fitur ini tidak tersedia di ruang kerja.
Koneksi terkelola untuk API OAuth 2.0
Dengan menggunakan pengelola kredensial, Anda dapat sangat menyederhanakan proses autentikasi dan otorisasi pengguna, grup, dan perwakilan layanan di satu atau beberapa layanan backend atau SaaS yang menggunakan OAuth 2.0. Menggunakan manajer kredensial API Management, dengan mudah mengonfigurasi OAuth 2.0, menyetujui, memperoleh token, token cache di penyimpanan kredensial, dan menyegarkan token tanpa menulis satu baris kode pun. Gunakan kebijakan akses untuk mendelegasikan autentikasi ke instans API Management, perwakilan layanan, pengguna, atau grup Anda. Untuk latar belakang tentang alur kode otorisasi OAuth 2.0, lihat platform identitas Microsoft dan OAuth 2.0.
Fitur ini memungkinkan API diekspos dengan atau tanpa kunci langganan, menggunakan otorisasi OAuth 2.0 untuk layanan backend, dan mengurangi biaya pengembangan dalam meningkatkan, menerapkan, dan memelihara fitur keamanan dengan integrasi layanan.
Contoh kasus penggunaan
Dengan menggunakan koneksi OAuth yang dikelola dalam API Management, pelanggan dapat dengan mudah terhubung ke penyedia SaaS atau layanan backend yang menggunakan OAuth 2.0. Berikut adalah beberapa contoh:
Terhubung dengan mudah ke backend SaaS dengan melampirkan token otorisasi yang disimpan dan permintaan proksi
Permintaan proksi ke aplikasi web Azure App Service atau backend Azure Functions dengan melampirkan token otorisasi, yang nantinya dapat mengirim permintaan ke backend SaaS yang menerapkan logika transformasi
Permintaan proksi ke backend federasi GraphQL dengan melampirkan beberapa token akses untuk melakukan federasi dengan mudah
Mengekspos titik akhir token yang diambil, memperoleh token cache, dan memanggil backend SaaS atas nama pengguna dari komputasi apa pun, misalnya, aplikasi konsol atau daemon Kubernetes. Gabungkan SDK SaaS favorit Anda dalam bahasa yang didukung.
Skenario tanpa pengawas Azure Functions saat menyambungkan ke beberapa backend SaaS.
Durable Functions mendapatkan langkah lebih dekat ke Logic Apps dengan konektivitas SaaS.
Dengan koneksi OAuth 2.0, setiap API di API Management dapat bertindak sebagai konektor kustom Logic Apps.
Bagaimana cara kerja manajer kredensial?
Kredensial token di pengelola kredensial terdiri dari dua bagian: manajemen dan runtime.
Bagian manajemen dalam pengelola kredensial menangani pengaturan dan konfigurasi penyedia kredensial untuk token OAuth 2.0, memungkinkan alur persetujuan untuk penyedia identitas, dan menyiapkan satu atau beberapa koneksi ke penyedia kredensial untuk akses ke kredensial. Untuk detailnya, lihat Manajemen koneksi.
Bagian runtime menggunakan
get-authorization-context
kebijakan untuk mengambil dan menyimpan token akses dan refresh koneksi. Ketika panggilan masuk ke API Management, danget-authorization-context
kebijakan dijalankan, panggilan pertama-tama memvalidasi apakah token otorisasi yang ada valid. Jika token otorisasi telah kedaluwarsa, API Management menggunakan alur OAuth 2.0 untuk me-refresh token yang disimpan dari idP. Kemudian token akses digunakan untuk mengotorisasi akses ke layanan backend. Untuk detailnya, lihat Runtime koneksi.
Kapan menggunakan manajer kredensial?
Berikut ini adalah tiga skenario untuk menggunakan manajer kredensial.
Skenario konfigurasi
Setelah mengonfigurasi penyedia info masuk dan koneksi, manajer API dapat menguji koneksi. Manajer API mengonfigurasi API OAuth backend pengujian untuk menggunakan get-authorization-context
kebijakan menggunakan identitas terkelola instans. Manajer API kemudian dapat menguji koneksi dengan memanggil API pengujian.
Skenario tanpa pengawas
Secara default saat koneksi dibuat, kebijakan akses dan koneksi telah dikonfigurasi sebelumnya untuk identitas terkelola instans API Management. Untuk menggunakan koneksi seperti itu, pengguna yang berbeda dapat masuk ke aplikasi klien seperti aplikasi web statis, yang kemudian memanggil API backend yang diekspos melalui API Management. Untuk melakukan panggilan ini, koneksi diterapkan menggunakan get-authorization-context
kebijakan. Karena panggilan API menggunakan koneksi yang telah dikonfigurasi sebelumnya yang tidak terkait dengan konteks pengguna, data yang sama dikembalikan ke semua pengguna.
Skenario yang dihadiri (didelegasikan pengguna)
Untuk mengaktifkan pengalaman autentikasi yang disederhanakan bagi pengguna aplikasi klien, seperti aplikasi web statis, yang memanggil API SaaS backend yang memerlukan konteks pengguna, Anda dapat mengaktifkan akses ke koneksi atas nama pengguna Microsoft Entra atau identitas grup. Dalam hal ini, pengguna yang dikonfigurasi perlu masuk dan memberikan persetujuan hanya sekali, dan instans API Management akan membuat dan mengelola koneksi mereka setelah itu. Ketika API Management mendapatkan panggilan masuk untuk diteruskan ke layanan eksternal, API Management melampirkan token akses dari koneksi ke permintaan. Ini sangat ideal ketika permintaan dan respons API diarahkan ke individu (misalnya, mengambil informasi profil khusus pengguna).
Bagaimana cara mengonfigurasi manajer kredensial?
Persyaratan
Identitas yang ditetapkan sistem terkelola harus diaktifkan untuk instans API Management.
Instans API Management harus memiliki konektivitas keluar ke internet di port 443 (HTTPS).
Ketersediaan
Semua tingkat layanan API Management
Tidak didukung di gateway yang dihost sendiri
Tidak didukung di sovereign cloud atau di wilayah berikut: australiacentral, australiacentral2, indiacentral
Contoh langkah demi langkah
- Mengonfigurasi pengelola kredensial - GITHub API
- Mengonfigurasi pengelola kredensial - Microsoft Graph API
- Mengonfigurasi pengelola kredensial - akses yang didelegasikan pengguna
Pertimbangan keamanan
Token akses dan rahasia lainnya (misalnya, rahasia klien) dienkripsi dengan enkripsi amplop dan disimpan dalam penyimpanan internal multipenyewa. Data dienkripsi dengan AES-128 menggunakan kunci yang unik per data. Kunci tersebut dienkripsi secara asimetris dengan sertifikat master yang disimpan di Azure Key Vault dan diputar setiap bulan.
Batas
Sumber daya | Batasan |
---|---|
Jumlah maksimum penyedia kredensial per instans layanan | 1,000 |
Jumlah maksimum koneksi per penyedia kredensial | 10,000 |
Jumlah maksimum kebijakan akses per koneksi | 100 |
Jumlah maksimum permintaan otorisasi per menit per koneksi | 250 |
Pertanyaan Umum (FAQ)
Kapan token akses di-refresh?
Untuk koneksi kode otorisasi jenis, token akses di-refresh sebagai berikut: Ketika get-authorization-context
kebijakan dijalankan pada runtime, API Management memeriksa apakah token akses tersimpan valid. Jika token telah kedaluwarsa atau hampir kedaluwarsa, API Management menggunakan token refresh untuk mengambil token akses baru dan token refresh baru dari IdP yang dikonfigurasi. Jika token refresh telah kedaluwarsa, kesalahan akan muncul, dan koneksi perlu diotorisasi ulang sebelum berhasil.
Apa yang terjadi jika rahasia klien kedaluwarsa di IdP?
Pada runtime API Management tidak dapat mengambil token baru, dan terjadi kesalahan.
Jika koneksi berjenis kode otorisasi, rahasia klien perlu diperbarui pada tingkat penyedia kredensial.
Jika koneksi berjenis kredensial klien, rahasia klien perlu diperbarui pada tingkat koneksi.
Apakah fitur ini didukung menggunakan API Management yang berjalan di dalam VNet?
Ya, selama konektivitas keluar pada port 443 diaktifkan ke tag layanan AzureConnectors . Untuk informasi selengkapnya, lihat Referensi konfigurasi jaringan virtual.
Apa yang terjadi ketika penyedia kredensial dihapus?
Semua koneksi dan kebijakan akses yang mendasar juga dihapus.
Apakah token akses di-cache oleh API Management?
Di tingkat layanan klasik dan v2, token akses di-cache oleh instans API Management hingga 3 menit sebelum waktu kedaluwarsa token. Jika token akses kurang dari 3 menit dari kedaluwarsa, waktu yang di-cache akan sampai token akses kedaluwarsa.
Token akses tidak di-cache di tingkat Konsumsi.
Konten terkait
- Mengonfigurasi penyedia kredensial untuk koneksi
- Mengonfigurasi dan menggunakan koneksi untuk Microsoft Graph API atau GITHub API
- Mengonfigurasi koneksi untuk akses yang didelegasikan pengguna
- Mengonfigurasi beberapa koneksi untuk penyedia kredensial