Bagikan melalui

Koneksi OAuth 2.0 di manajer kredensial - detail dan alur proses

BERLAKU UNTUK: Semua tingkatan Manajemen API

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.

Diagram memperlihatkan alur proses untuk membuat kredensial.

Langkah Deskripsi
1 Klien mengirimkan permintaan untuk membuat penyedia kredensial.
2 Penyedia kredensial dibuat dan tanggapan dikirim kembali.
3 Klien mengirim permintaan untuk membuat koneksi.
4 Koneksi 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 ini mencakup URL pasca-pengalihan yang akan digunakan pada 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 kredensial.
8 Setelah persetujuan disetujui, browser dialihkan dengan kode otorisasi ke URL pengalihan yang dikonfigurasi di penyedia kredensial.
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.

Nota

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 membuat penyimpanan kredensial di latar belakang 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, Anda memerlukan dua konfigurasi penyedia kredensial. Tabel berikut ini meringkas dua jenis pemberian.

Jenis pemberian Deskripsi
Kode otorisasi Terikat ke konteks pengguna, yang berarti pengguna perlu menyetujui koneksi. Selama token penyegaran masih valid, API Management dapat mengambil token akses dan penyegaran yang baru. Jika token refresh menjadi tidak valid, pengguna perlu mengotorisasi ulang. Semua penyedia kredensial mendukung kode otorisasi. Pelajari lebih lanjut
Kredensial pelanggan 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

Untuk koneksi berdasarkan jenis pemberian kode otorisasi, Anda harus mengautentikasi ke penyedia dan menyetujui otorisasi. Setelah berhasil masuk dan otorisasi oleh penyedia kredensial, penyedia tersebut mengembalikan token akses dan refresh yang valid, yang dienkripsi dan disimpan oleh manajemen API.

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 prinsipal layanan, identitas instans API Management Anda, pengguna, dan grup.

Identitas Deskripsi Keuntungan Pertimbangan
Prinsipal 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. Prinsipal layanan adalah identitas Microsoft Entra yang mewakili aplikasi Microsoft Entra yang terdaftar. Mengizinkan akses yang lebih terfokus pada skenario koneksi dan delegasi pengguna. Tidak terkait dengan instans API Management tertentu. Bergantung pada ID Microsoft Entra untuk penegakan izin. Mendapatkan konteks otorisasi memerlukan token ID Microsoft Entra.
Identitas yang dikelola <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.

Waktu proses koneksi

Bagian runtime memerlukan API OAuth 2.0 backend untuk dikonfigurasi dengan kebijakan get-authorization-context . Saat runtime, kebijakan mengambil dan menyimpan akses serta token refresh dari penyimpanan kredensial yang disiapkan oleh API Management untuk penyedia layanan. Ketika panggilan masuk ke API Management dan kebijakan get-authorization-context dijalankan, pertama-tama memvalidasi apakah token otorisasi yang ada sah. 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.

Diagram yang menunjukkan alur proses untuk mengambil token saat runtime.

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 kredensial mengembalikan token akses dan token refresh, yang dienkripsi dan disimpan dalam API Management.
5 Setelah token diambil, token akses dilampirkan menggunakan kebijakan set-header sebagai header otorisasi ke permintaan ke luar menuju API backend.
6 Respons dikembalikan ke API Management.
7 Respons dikembalikan ke klien.

Konten terkait

  • Last updated on