Tentang kredensial API dan manajer kredensial

  • Artikel

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.

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.

Diagram manajer kredensial API Management dan idP SaaS yang didukung.

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, dan get-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.

Diagram skenario konfigurasi awal untuk manajer kredensial.

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.

Diagram skenario identitas terkelola untuk manajer kredensial.

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).

Diagram skenario yang didelegasikan pengguna untuk manajer kredensial.

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

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 Azure Koneksi ors. 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