Koneksi OAuth 2.0 di manajer kredensial - detail dan alur proses
BERLAKU UNTUK: Semua tingkatAN API Management
Artikel ini menyediakan detail tentang alur proses untuk mengelola koneksi OAuth 2.0 menggunakan pengelola kredensial di Azure API Management. Alur proses dibagi menjadi dua bagian: manajemen dan runtime.
Untuk latar belakang tentang manajer kredensial di API Management, lihat Tentang kredensial manager dan kredensial API di API Management.
Manajemen koneksi
Bagian manajemen koneksi di pengelola kredensial menangani pengaturan dan konfigurasi penyedia kredensial untuk token OAuth 2.0, memungkinkan alur persetujuan untuk penyedia, dan menyiapkan satu atau beberapa koneksi ke penyedia kredensial untuk akses ke kredensial.
Gambar berikut meringkas alur proses untuk membuat koneksi di API Management yang menggunakan jenis pemberian kode otorisasi.
| Langkah | Deskripsi |
|---|---|
| 1 | Klien mengirim permintaan untuk membuat penyedia kredensial |
| 2 | Penyedia kredensial dibuat, dan respons dikirim kembali |
| 3 | Klien mengirim permintaan untuk membuat koneksi |
| 4 | Koneksi ion dibuat, dan respons dikirim kembali dengan informasi bahwa koneksi tidak "tersambung" |
| 5 | Klien mengirimkan permintaan untuk mengambil URL masuk untuk memulai persetujuan OAuth 2.0 di penyedia kredensial. Permintaan menyertakan URL pasca-pengalihan yang akan digunakan di langkah terakhir |
| 6 | Respons dikembalikan dengan URL masuk yang harus digunakan untuk memulai alur persetujuan. |
| 7 | Klien membuka browser dengan URL masuk yang disediakan di langkah sebelumnya. Browser dialihkan ke alur persetujuan OAuth 2.0 penyedia info masuk |
| 8 | Setelah persetujuan disetujui, browser dialihkan dengan kode otorisasi ke URL pengalihan yang dikonfigurasi di penyedia info masuk |
| 9 | API Management menggunakan kode otorisasi untuk mengambil akses dan menyegarkan token |
| 10 | API Management menerima token dan mengenkripsinya |
| 11 | API Management mengalihkan ke URL yang disediakan dari langkah 5 |
Penyedia kredensial
Saat mengonfigurasi penyedia kredensial, Anda dapat memilih antara penyedia OAuth yang berbeda dan jenis pemberian (kode otorisasi atau kredensial klien). Setiap penyedia memerlukan konfigurasi tertentu. Hal-hal penting yang perlu diingat:
- Konfigurasi penyedia kredensial hanya dapat memiliki satu jenis hibah.
- Satu konfigurasi penyedia info masuk dapat memiliki beberapa koneksi.
Catatan
Dengan penyedia Generic OAuth 2.0, penyedia identitas lain yang mendukung standar alur OAuth 2.0 dapat digunakan.
Saat Anda mengonfigurasi penyedia kredensial, manajer kredensial di balik layar membuat penyimpanan kredensial yang digunakan untuk menyimpan token akses OAuth 2.0 penyedia dan menyegarkan token.
Koneksi ke penyedia kredensial
Untuk mengakses dan menggunakan token untuk penyedia, aplikasi klien memerlukan koneksi ke penyedia kredensial. Koneksi tertentu diizinkan oleh kebijakan akses berdasarkan identitas ID Microsoft Entra. Anda dapat mengonfigurasi beberapa koneksi untuk penyedia.
Proses mengonfigurasi koneksi berbeda berdasarkan pemberian yang dikonfigurasi dan khusus untuk konfigurasi penyedia kredensial. Misalnya, jika Anda ingin mengonfigurasi ID Microsoft Entra untuk menggunakan kedua jenis pemberian, diperlukan dua konfigurasi penyedia kredensial. Tabel berikut ini meringkas dua jenis pemberian.
| Jenis hibah | Deskripsi |
|---|---|
| Kode otorisasi | Terikat ke konteks pengguna, yang berarti pengguna perlu menyetujui koneksi. Selama token refresh valid, API Management dapat mengambil token akses dan refresh baru. Jika token refresh menjadi tidak valid, pengguna perlu mengotorisasi ulang. Semua penyedia kredensial mendukung kode otorisasi. Pelajari lebih lanjut |
| Informasi masuk klien | Tidak terikat dengan pengguna dan sering digunakan dalam skenario aplikasi-ke-aplikasi. Tidak ada persetujuan yang diperlukan untuk jenis pemberian kredensial klien, dan koneksi tidak menjadi tidak valid. Pelajari lebih lanjut |
Persetujuan
Untuk koneksi berdasarkan jenis pemberian kode otorisasi, Anda harus mengautentikasi ke penyedia dan menyetujui otorisasi. Setelah berhasil masuk dan otorisasi oleh penyedia info masuk, penyedia mengembalikan akses dan token refresh yang valid, yang dienkripsi dan disimpan oleh API Management.
Kebijakan akses
Anda mengonfigurasi satu atau beberapa kebijakan akses untuk setiap koneksi. Kebijakan akses menentukan identitas ID Microsoft Entra mana yang dapat memperoleh akses ke kredensial Anda saat runtime. Koneksi saat ini mendukung akses menggunakan perwakilan layanan, identitas, pengguna, dan grup instans API Management Anda.
| Identitas | Deskripsi | Keuntungan | Pertimbangan |
|---|---|---|---|
| Perwakilan layanan | Identitas yang tokennya dapat digunakan untuk mengautentikasi dan memberikan akses ke sumber daya Azure tertentu, saat organisasi menggunakan ID Microsoft Entra. Dengan menggunakan perwakilan layanan, organisasi menghindari pembuatan pengguna fiktif untuk mengelola autentikasi saat mereka perlu mengakses sumber daya. Perwakilan layanan adalah identitas Microsoft Entra yang mewakili aplikasi Microsoft Entra terdaftar. | Mengizinkan akses yang lebih ketat ke skenario delegasi koneksi dan pengguna. Tidak terkait dengan instans API Management tertentu. Bergantung pada ID Microsoft Entra untuk penerapan izin. | Mendapatkan konteks otorisasi memerlukan token ID Microsoft Entra. |
Identitas terkelola <Your API Management instance name> |
Opsi ini sesuai dengan identitas terkelola yang terkait dengan instans API Management Anda. | Secara default, akses diberikan ke identitas terkelola yang ditetapkan sistem untuk instans manajemen API yang sesuai. | Identitas terkait dengan instans API Management Anda. Siapa pun dengan akses Kontributor ke instans API Management dapat mengakses koneksi apa pun yang memberikan izin identitas terkelola. |
| Pengguna atau grup | Pengguna atau grup di penyewa MICROSOFT Entra ID Anda. | Memungkinkan Anda membatasi akses ke pengguna atau grup pengguna tertentu. | Mengharuskan pengguna memiliki akun ID Microsoft Entra. |
Runtime koneksi
Bagian runtime memerlukan API OAuth 2.0 backend untuk dikonfigurasi dengan get-authorization-context kebijakan. Pada runtime, kebijakan mengambil dan menyimpan akses dan me-refresh token dari penyimpanan kredensial yang disiapkan API Management untuk penyedia. 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 penyedia info masuk. Kemudian token akses digunakan untuk mengotorisasi akses ke layanan backend.
Selama eksekusi kebijakan, akses ke token juga divalidasi menggunakan kebijakan akses.
Gambar berikut menunjukkan contoh alur proses untuk mengambil dan menyimpan otorisasi dan menyegarkan token berdasarkan koneksi yang menggunakan jenis pemberian kode otorisasi. Setelah token diambil, panggilan dilakukan ke API backend.
| Langkah | Deskripsi |
|---|---|
| 1 | Klien mengirim permintaan ke instans API Management |
| 2 | Kebijakan get-authorization-context memeriksa apakah token akses valid untuk koneksi saat ini |
| 3 | Jika token akses telah kedaluwarsa tetapi token refresh valid, API Management mencoba mengambil akses baru dan menyegarkan token dari penyedia kredensial yang dikonfigurasi |
| 4 | Penyedia info masuk mengembalikan token akses dan token refresh, yang dienkripsi dan disimpan ke API Management |
| 5 | Setelah token diambil, token akses dilampirkan menggunakan set-header kebijakan sebagai header otorisasi ke permintaan keluar ke API backend |
| 6 | Respons dikembalikan ke API Management |
| 7 | Respons dikembalikan ke klien |
Konten terkait
- Gambaran umum manajer kredensial
- Mengonfigurasi penyedia kredensial untuk manajer kredensial
- Mengonfigurasi dan menggunakan koneksi untuk Microsoft Graph API atau GITHub API
- Mengonfigurasi beberapa koneksi otorisasi untuk penyedia
- Mengonfigurasi koneksi untuk akses yang didelegasikan pengguna