Bagikan melalui

Autentikasi dan otorisasi ke API di Azure API Management

  • Artikel

BERLAKU UNTUK: Semua tingkatAN API Management

Artikel ini adalah pengantar serangkaian fitur yang kaya dan fleksibel di API Management yang membantu Anda mengamankan akses pengguna ke API terkelola.

Autentikasi dan otorisasi API di API Management melibatkan komunikasi end-to-end aplikasi klien melalui gateway API Management ke API backend. Di banyak lingkungan pelanggan, OAuth 2.0 adalah protokol otorisasi API pilihan. API Management mendukung otorisasi OAuth 2.0 antara klien dan gateway API Management, antara gateway dan API backend, atau keduanya secara independen.

Diagram memperlihatkan titik interaksi untuk mengamankan API.

API Management mendukung mekanisme autentikasi dan otorisasi sisi klien dan sisi layanan lainnya yang melengkapi OAuth 2.0 atau yang berguna ketika otorisasi OAuth 2.0 untuk API tidak dimungkinkan. Cara Anda memilih dari antara opsi ini tergantung pada kematangan lingkungan API organisasi Anda, persyaratan keamanan dan kepatuhan Anda, dan pendekatan organisasi Anda untuk mengurangi ancaman API umum.

Penting

Mengamankan akses pengguna ke API adalah salah satu dari banyak pertimbangan untuk mengamankan lingkungan API Management Anda. Untuk mengetahui informasi selengkapnya, lihat dasar keamanan Azure untuk API Management.

Catatan

Komponen API Management lainnya memiliki mekanisme terpisah untuk mengamankan dan membatasi akses pengguna:

  • Untuk mengelola instans API Management melalui sarana kontrol Azure, API Management bergantung pada ID Microsoft Entra dan kontrol akses berbasis peran Azure (RBAC).
  • Portal pengembang API Management mendukung beberapa opsi untuk memfasilitasi pendaftaran dan masuk pengguna yang aman.

Perbandingan autentikasi dan otorisasi

Berikut adalah penjelasan singkat tentang autentikasi dan otorisasi dalam konteks akses ke API:

  • Autentikasi - Proses memverifikasi identitas pengguna atau aplikasi yang mengakses API. Autentikasi dapat dilakukan melalui kredensial seperti nama pengguna dan kata sandi, sertifikat, atau melalui akses menyeluruh (SSO) atau metode lainnya.

  • Otorisasi - Proses menentukan apakah pengguna atau aplikasi memiliki izin untuk mengakses API tertentu, seringkali melalui protokol berbasis token seperti OAuth 2.0.

Catatan

Untuk melengkapi autentikasi dan otorisasi, akses ke API juga harus diamankan menggunakan TLS untuk melindungi kredensial atau token yang digunakan untuk autentikasi atau otorisasi.

Konsep OAuth 2.0

OAuth 2.0 adalah kerangka kerja otorisasi standar yang banyak digunakan untuk mengamankan akses ke sumber daya seperti API web. OAuth 2.0 membatasi tindakan apa yang dapat dilakukan aplikasi klien pada sumber daya atas nama pengguna, tanpa pernah berbagi kredensial pengguna. Meskipun OAuth 2.0 bukan protokol autentikasi, OAuth 2.0 sering digunakan dengan OpenID Koneksi (OIDC), yang memperluas OAuth 2.0 dengan menyediakan autentikasi pengguna dan fungsionalitas SSO.

Alur OAuth

Apa yang terjadi ketika aplikasi klien memanggil API dengan permintaan yang diamankan menggunakan TLS dan OAuth 2.0? Berikut ini adalah contoh alur yang disingkat:

  • Klien (aplikasi panggilan, atau pembawa) mengautentikasi menggunakan kredensial ke penyedia identitas.

  • Klien mendapatkan token akses terbatas waktu (token web JSON, atau JWT) dari server otorisasi penyedia identitas.

    IdP (misalnya, ID Microsoft Entra) adalah penerbit token, dan token menyertakan klaim audiens yang mengotorisasi akses ke server sumber daya (misalnya, ke API backend, atau ke gateway API Management itu sendiri).

  • Klien memanggil API dan menyajikan token akses - misalnya, di header Otorisasi.

  • Server sumber daya memvalidasi token akses. Validasi adalah proses kompleks yang mencakup pemeriksaan bahwa klaim penerbit dan audiens berisi nilai yang diharapkan.

  • Berdasarkan kriteria validasi token, akses ke sumber daya API backend kemudian diberikan.

Bergantung pada jenis aplikasi dan skenario klien, alur otorisasi yang berbeda diperlukan untuk meminta dan mengelola token. Misalnya, alur kode otorisasi dan jenis pemberian umumnya digunakan dalam aplikasi yang memanggil API web. Pelajari selengkapnya tentang alur OAuth dan skenario aplikasi di ID Microsoft Entra.

Skenario otorisasi OAuth 2.0 dalam API Management

Skenario 1 - Aplikasi klien mengotorisasi langsung ke backend

Skenario otorisasi umum adalah ketika aplikasi panggilan meminta akses ke API backend secara langsung dan menyajikan token OAuth 2.0 di header otorisasi ke gateway. Azure API Management kemudian bertindak sebagai proksi "transparan" antara PEManggil dan API backend, dan meneruskan token melalui tidak berubah ke backend. Cakupan token akses adalah antara aplikasi panggilan dan API backend.

Gambar berikut menunjukkan contoh di mana ID Microsoft Entra adalah penyedia otorisasi. Aplikasi klien mungkin merupakan aplikasi satu halaman (SPA).

Diagram yang menunjukkan komunikasi OAuth dengan audiens sebagai backend.

Meskipun token akses yang dikirim bersama dengan permintaan HTTP ditujukan untuk API backend, API Management masih memungkinkan pendekatan pertahanan mendalam. Misalnya, konfigurasikan kebijakan untuk memvalidasi JWT, menolak permintaan yang tiba tanpa token, atau token yang tidak valid untuk API backend yang dimaksudkan. Anda juga dapat mengonfigurasi API Management untuk memeriksa klaim minat lain yang diekstrak dari token.

Catatan

Jika Anda mengamankan API yang diekspos melalui Azure API Management dengan OAuth 2.0 dengan cara ini, Anda dapat mengonfigurasi API Management untuk menghasilkan token yang valid untuk tujuan pengujian atas nama pengguna konsol pengujian portal portal Azure atau pengembang. Anda perlu menambahkan server OAuth 2.0 ke instans API Management Anda dan mengaktifkan pengaturan otorisasi OAuth 2.0 di API. Untuk informasi selengkapnya, lihat Cara mengotorisasi konsol pengujian portal pengembang dengan mengonfigurasi otorisasi pengguna OAuth 2.0.

Contoh:

Tip

Dalam kasus khusus ketika akses API dilindungi menggunakan MICROSOFT Entra ID, Anda dapat mengonfigurasi kebijakan validasi-azure-ad-token untuk validasi token.

Skenario 2 - Aplikasi klien mengotorisasi ke API Management

Dalam skenario ini, layanan API Management bertindak atas nama API, dan aplikasi panggilan meminta akses ke instans API Management. Cakupan token akses adalah antara aplikasi panggilan dan gateway API Management. Di API Management, konfigurasikan kebijakan (validate-jwt atau validate-azure-ad-token) untuk memvalidasi token sebelum gateway meneruskan permintaan ke backend. Mekanisme terpisah biasanya mengamankan koneksi antara gateway dan API backend.

Dalam contoh berikut, ID Microsoft Entra kembali menjadi penyedia otorisasi, dan autentikasi TLS bersama (mTLS) mengamankan koneksi antara gateway dan backend.

Diagram yang menunjukkan komunikasi OAuth dengan audiens sebagai gateway API Management.

Ada berbagai alasan untuk melakukan ini. Contohnya:

  • Backend adalah API warisan yang tidak dapat diperbarui untuk mendukung OAuth

    API Management harus dikonfigurasi terlebih dahulu untuk memvalidasi token (memeriksa klaim penerbit dan audiens minimal). Setelah validasi, gunakan salah satu dari beberapa opsi yang tersedia untuk mengamankan koneksi dan seterusnya dari API Management, seperti autentikasi TLS bersama (mTLS). Lihat Opsi sisi layanan, nanti di artikel ini.

  • Konteks yang diperlukan oleh backend tidak dimungkinkan untuk dibuat dari pemanggil

    Setelah API Management berhasil memvalidasi token yang diterima dari pemanggil, maka perlu mendapatkan token akses untuk API backend menggunakan konteksnya sendiri, atau konteks yang berasal dari aplikasi panggilan. Skenario ini dapat dicapai menggunakan:

    • Kebijakan kustom seperti kirim permintaan untuk mendapatkan token akses seterusnya yang valid untuk API backend dari penyedia identitas yang dikonfigurasi.

    • Identitas instans API Management sendiri – meneruskan token dari identitas terkelola yang ditetapkan sistem sumber daya API Management atau yang ditetapkan pengguna ke API backend.

  • Organisasi ingin mengadopsi pendekatan otorisasi standar

    Terlepas dari mekanisme autentikasi dan otorisasi pada backend API mereka, organisasi dapat memilih untuk bertemu dengan OAuth 2.0 untuk pendekatan otorisasi standar di ujung depan. Gateway API Management dapat memungkinkan konfigurasi otorisasi yang konsisten dan pengalaman umum bagi konsumen API seiring berkembangnya backend organisasi.

Skenario 3: API Management mengotorisasi backend

Dengan koneksi terkelola (sebelumnya disebut otorisasi), Anda menggunakan pengelola kredensial di API Management untuk mengotorisasi akses ke satu atau beberapa layanan backend atau SaaS, seperti LinkedIn, GitHub, atau backend yang kompatibel dengan OAuth 2.0 lainnya. Dalam skenario ini, aplikasi pengguna atau klien membuat permintaan ke gateway API Management, dengan akses gateway dikontrol menggunakan penyedia identitas atau opsi sisi klien lainnya. Kemudian, melalui konfigurasi kebijakan, aplikasi pengguna atau klien mendelegasikan autentikasi dan otorisasi backend ke API Management.

Dalam contoh berikut, kunci langganan digunakan antara klien dan gateway, dan GitHub adalah penyedia kredensial untuk API backend.

Diagram memperlihatkan otorisasi ke layanan SaaS backend menggunakan koneksi yang dikelola di pengelola kredensial.

Dengan koneksi ke penyedia info masuk, API Management memperoleh dan merefresh token untuk akses API dalam alur OAuth 2.0. Koneksi menyederhanakan manajemen token dalam beberapa skenario, seperti:

  • Aplikasi klien mungkin perlu mengotorisasi ke beberapa backend SaaS untuk menyelesaikan beberapa bidang menggunakan pemecah masalah GraphQL.
  • Pengguna mengautentikasi ke API Management oleh SSO dari penyedia identitas mereka, tetapi mengotorisasi ke penyedia SaaS backend (seperti LinkedIn) menggunakan akun organisasi umum.
  • Aplikasi klien (atau bot) perlu mengakses sumber daya online aman backend atas nama pengguna yang diautentikasi (misalnya, memeriksa email atau melakukan pesanan).

Contoh:

Opsi lain untuk mengamankan API

Meskipun otorisasi lebih disukai, dan OAuth 2.0 telah menjadi metode dominan untuk mengaktifkan otorisasi yang kuat untuk API, API Management menyediakan beberapa mekanisme lain untuk mengamankan atau membatasi akses antara klien dan gateway (sisi klien) atau antara gateway dan backend (sisi layanan). Tergantung pada persyaratan organisasi, ini dapat digunakan untuk melengkapi OAuth 2.0. Atau, konfigurasikan secara independen jika aplikasi panggilan atau API backend warisan atau belum mendukung OAuth 2.0.

Opsi sisi klien

Mekanisme Deskripsi Pertimbangan
mTLS Memvalidasi sertifikat yang disajikan oleh klien yang menghubungkan dan memeriksa properti sertifikat terhadap sertifikat yang dikelola di API Management Sertifikat dapat disimpan dalam brankas kunci.
Batasi IP pemanggil Memfilter panggilan (izinkan/tolak) dari alamat IP atau rentang alamat tertentu. Gunakan untuk membatasi akses ke pengguna atau organisasi tertentu, atau untuk lalu lintas dari layanan hulu.
Kunci langganan Membatasi akses ke satu atau beberapa API berdasarkan langganan API Management Sebaiknya gunakan kunci langganan (API) selain metode autentikasi atau otorisasi lain. Sendiri, kunci langganan bukan bentuk autentikasi yang kuat, tetapi penggunaan kunci langganan mungkin berguna dalam skenario tertentu, misalnya, melacak penggunaan API pelanggan individu atau memberikan akses ke produk API tertentu.

Tip

Untuk pertahanan secara mendalam, menyebarkan firewall aplikasi web di hulu instans API Management sangat disarankan. Misalnya, gunakan Azure Application Gateway atau Azure Front Door.

Opsi sisi layanan

Mekanisme Deskripsi Pertimbangan
Autentikasi identitas terkelola Autentikasi ke API backend dengan identitas terkelola yang ditetapkan sistem atau ditetapkan pengguna. Direkomendasikan untuk akses terlingkup ke sumber daya backend yang dilindungi dengan mendapatkan token dari ID Microsoft Entra.
Autentikasi sertifikat Autentikasi ke API backend menggunakan sertifikat klien. Sertifikat dapat disimpan dalam brankas kunci.
Autentikasi dasar Autentikasi ke API backend dengan nama pengguna dan kata sandi yang diteruskan melalui header Otorisasi. Tidak disarankan jika opsi yang lebih baik tersedia.

Langkah berikutnya