Skenario: Aplikasi daemon yang memanggil API web

  • Artikel

Skenario ini akan memandu Anda untuk membangun aplikasi daemon yang memanggil API web.

Gambaran Umum

Aplikasi Anda dapat memperoleh token untuk memanggil API web atas nama dirinya sendiri (bukan atas nama pengguna). Skenario ini berguna untuk aplikasi daemon. Ini menggunakan pemberian informasi masuk klien OAuth 2.0 standar.

Daemon apps

Beberapa contoh kasus penggunaan untuk aplikasi daemon meliputi;

  • Aplikasi web yang digunakan untuk menyediakan atau mengelola pengguna atau melakukan proses batch di dalam direktori
  • Aplikasi desktop (seperti layanan Windows pada proses Windows atau daemon di Linux) yang melakukan pekerjaan batch, atau layanan sistem operasi yang berjalan di latar belakang
  • API Web yang perlu memanipulasi direktori, bukan pengguna tertentu

Ada kasus umum lain di mana aplikasi non-daemon menggunakan kredensial klien, bahkan ketika mereka bertindak atas nama pengguna. Ini terjadi ketika mereka perlu mengakses API web atau sumber daya di bawah identitas mereka sendiri karena alasan teknis. Contohnya adalah akses ke rahasia di Azure Key Vault atau Azure SQL Database untuk cache.

Anda tidak dapat menyebarkan aplikasi daemon ke perangkat pengguna biasa, dan pengguna biasa tidak dapat mengakses aplikasi daemon. Hanya sekumpulan administrator TI terbatas yang dapat mengakses perangkat yang menjalankan aplikasi daemon. Ini agar aktor jahat tidak dapat mengakses rahasia klien atau token dari lalu lintas perangkat dan bertindak atas nama aplikasi daemon. Skenario aplikasi daemon tidak menggantikan autentikasi perangkat.

Contoh aplikasi non-daemon:

  • Aplikasi seluler yang mengakses layanan web atas nama aplikasi, tetapi tidak atas nama pengguna.
  • Perangkat IoT yang mengakses layanan web atas nama perangkat, tetapi tidak atas nama pengguna.

Aplikasi yang memperoleh token untuk identitasnya sendiri:

  • Aplikasi klien rahasia, mengingat bahwa mereka mengakses sumber daya secara independen dari pengguna, perlu membuktikan identitas mereka. Admin penyewa Microsoft Entra perlu memberikan persetujuan ke aplikasi yang agak sensitif ini.
  • Telah mendaftarkan rahasia (kata sandi atau sertifikat aplikasi) dengan ID Microsoft Entra. Rahasia ini diteruskan selama panggilan ke MICROSOFT Entra ID untuk mendapatkan token.

Rincian

Pengguna tidak dapat berinteraksi dengan aplikasi daemon karena memerlukan identitasnya sendiri. Jenis aplikasi ini meminta token akses dengan menggunakan identitas aplikasinya dan menyajikan ID aplikasi, kredensial (kata sandi atau sertifikat), dan URI ID aplikasi ke ID Microsoft Entra. Setelah autentikasi berhasil, daemon menerima token akses (dan token refresh) dari platform identitas Microsoft. Token ini kemudian digunakan untuk memanggil API web (dan disegarkan sesuai kebutuhan).

Karena pengguna tidak dapat berinteraksi dengan aplikasi daemon, persetujuan inkremental tidak dimungkinkan. Semua izin API yang diperlukan perlu dikonfigurasi pada pendaftaran aplikasi. Kode aplikasi hanya meminta izin yang ditentukan secara statis. Ini juga berarti bahwa aplikasi daemon tidak akan mendukung persetujuan inkremental.

Untuk pengembang, pengalaman end-to-end untuk skenario ini memiliki aspek-aspek berikut:

  • Aplikasi Daemon hanya dapat berfungsi di penyewa Microsoft Entra. Tidak masuk akal untuk membangun aplikasi daemon yang mencoba memanipulasi akun pribadi Microsoft. Jika Anda seorang pengembang aplikasi line-of-business (LOB), Anda akan membuat aplikasi daemon di penyewa Anda. Jika Anda seorang ISV, Anda mungkin ingin membuat aplikasi daemon multipenyewa. Setiap admin penyewa perlu memberikan persetujuan.
  • Selama pendaftaran aplikasi, URI balasan tidak diperlukan. Bagikan rahasia atau sertifikat atau pernyataan yang ditandatangani dengan ID Microsoft Entra. Anda juga perlu meminta izin aplikasi dan memberi persetujuan admin untuk menggunakan izin aplikasi tersebut.
  • Konfigurasi aplikasi perlu memberikan kredensial klien seperti yang dibagikan dengan ID Microsoft Entra selama pendaftaran aplikasi.
  • Cakupan yang digunakan untuk memperoleh token dengan alur informasi masuk klien harus merupakan cakupan statis.

Jika Anda baru mengenal manajemen identitas dan akses (IAM) dengan OAuth 2.0 dan OpenID Connect, atau bahkan baru mengenal IAM di platform identitas Microsoft, kumpulan artikel berikut ini harus ada di urutan atas dalam daftar bacaan Anda.

Meskipun tidak wajib membaca sebelum menyelesaikan mulai cepat atau tutorial pertama Anda, artikel tersebut membahas topik yang terkait dengan platform, dan terbiasa dengan topik tersebut akan membantu Anda di jalur Anda saat Anda membangun skenario yang lebih kompleks.

Autentikasi dan Otorisasi

Platform identitas Microsoft

Langkah berikutnya

Beralih ke artikel berikutnya dalam skenario ini, Pendaftaran aplikasi.