Mengamankan aplikasi dan API dengan memvalidasi klaim

  • Artikel

Berinteraksi dengan token adalah bagian inti dari membangun aplikasi untuk mengotorisasi pengguna. Sesuai dengan prinsip Zero Trust untuk akses dengan hak istimewa paling sedikit, penting bagi aplikasi untuk memvalidasi nilai klaim tertentu yang ada dalam token akses saat melakukan otorisasi.

Otorisasi berbasis klaim memungkinkan aplikasi untuk memastikan bahwa token berisi nilai yang benar untuk hal-hal seperti penyewa, subjek, dan aktor yang ada dalam token. Meskipun demikian, otorisasi berbasis klaim dapat tampak kompleks mengingat berbagai metode untuk memanfaatkan dan skenario untuk dilacak. Artikel ini bermasalah untuk menyederhanakan proses otorisasi berbasis klaim sehingga Anda dapat memastikan aplikasi Anda mematuhi praktik yang paling aman.

Untuk memastikan bahwa logika otorisasi Anda aman, Anda harus memvalidasi informasi berikut dalam klaim:

  • Audiens yang sesuai ditentukan untuk token.
  • ID penyewa token cocok dengan ID penyewa tempat data disimpan.
  • Subjek token sesuai.
  • Aktor (aplikasi klien) diotorisasi.

Catatan

Token akses hanya divalidasi di API web tempat token tersebut diperoleh oleh klien. Klien tidak boleh memvalidasi token akses.

Untuk informasi selengkapnya tentang klaim yang disebutkan dalam artikel ini, lihat platform identitas Microsoft token akses.

Memvalidasi audiens

Klaim aud mengidentifikasi audiens token yang dimaksudkan. Sebelum memvalidasi klaim, Anda harus selalu memverifikasi bahwa nilai aud klaim yang terkandung dalam token akses cocok dengan API Web. Nilai dapat bergantung pada cara klien meminta token. Audiens dalam token akses tergantung pada titik akhir:

  • Untuk token v2.0, audiens adalah ID klien api web. Ini guid.
  • Untuk token v1.0, audiens adalah salah satu URI appID yang dideklarasikan dalam API web yang memvalidasi token. Misalnya, api://{ApplicationID}, atau nama unik yang dimulai dengan nama domain (jika nama domain dikaitkan dengan penyewa).

Untuk informasi selengkapnya tentang URI appID aplikasi, lihat URI ID Aplikasi.

Memvalidasi penyewa

Selalu periksa apakah tid dalam token cocok dengan ID penyewa yang digunakan untuk menyimpan data dengan aplikasi. Ketika informasi disimpan untuk aplikasi dalam konteks penyewa, informasi hanya boleh diakses lagi nanti di penyewa yang sama. Jangan pernah mengizinkan data dalam satu penyewa diakses dari penyewa lain.

Validasi penyewa hanyalah langkah pertama, dan pemeriksaan subjek dan aktor yang dijelaskan dalam artikel ini masih diperlukan. Jika niat Anda adalah untuk mengotorisasi semua pengguna dalam penyewa, sangat disarankan untuk secara eksplisit menambahkan pengguna ini ke dalam grup dan mengotorisasi berdasarkan grup. Misalnya, dengan hanya memeriksa ID penyewa dan keberadaan oid klaim, API Anda secara tidak sengaja dapat mengotorisasi semua perwakilan layanan di penyewa tersebut selain pengguna.

Memvalidasi subjek

Tentukan apakah subjek token, seperti pengguna (atau aplikasi itu sendiri untuk token khusus aplikasi), diotorisasi.

Anda dapat memeriksa klaim atau oid tertentusub.

Atau,

Anda dapat memeriksa bahwa subjek termasuk dalam peran atau grup yang sesuai dengan rolesklaim , groups, wids . Misalnya, gunakan nilai tid klaim yang tidak dapat diubah dan oid sebagai kunci gabungan untuk data aplikasi dan menentukan apakah pengguna harus diberikan akses.

rolesKlaim , groups atau wids juga dapat digunakan untuk menentukan apakah subjek memiliki otorisasi untuk melakukan operasi. Misalnya, administrator mungkin memiliki izin untuk menulis ke API, tetapi bukan pengguna normal, atau pengguna mungkin berada dalam grup yang diizinkan untuk melakukan beberapa tindakan. Klaim mewakili wid peran seluruh penyewa yang ditetapkan kepada pengguna dari peran yang ada dalam peran bawaan Microsoft Entra. Untuk informasi selengkapnya, lihat Peran bawaan Microsoft Entra.

Peringatan

Jangan pernah menggunakan klaim seperti email, preferred_username atau unique_name untuk menyimpan atau menentukan apakah pengguna dalam token akses harus memiliki akses ke data. Klaim ini tidak unik dan dapat dikontrol oleh administrator penyewa atau terkadang pengguna, yang membuatnya tidak cocok untuk keputusan otorisasi. Mereka hanya dapat digunakan untuk tujuan tampilan. Juga jangan gunakan upn klaim untuk otorisasi. Meskipun UPN unik, upn sering berubah selama masa pakai prinsipal pengguna, yang membuatnya tidak dapat diandalkan untuk otorisasi.

Memvalidasi aktor

Aplikasi klien yang bertindak atas nama pengguna (disebut sebagai aktor), juga harus diotorisasi. scp Gunakan klaim (cakupan) untuk memvalidasi bahwa aplikasi memiliki izin untuk melakukan operasi. Izin di harus terbatas pada scp apa yang sebenarnya dibutuhkan pengguna dan mengikuti prinsip-prinsip hak istimewa paling sedikit.

Namun, ada kemunculan di mana scp tidak ada dalam token. Anda harus memeriksa tidak adanya scp klaim untuk skenario berikut:

  • Izin hanya aplikasi / aplikasi Daemon
  • Token ID

Untuk informasi selengkapnya tentang cakupan dan izin, lihat Cakupan dan izin di platform identitas Microsoft.

Catatan

Aplikasi dapat menangani token khusus aplikasi (permintaan dari aplikasi tanpa pengguna, seperti aplikasi daemon) dan ingin mengotorisasi aplikasi tertentu di beberapa penyewa, bukan ID perwakilan layanan individual. Dalam hal ini, appid klaim (untuk token v1.0) atau azp klaim (untuk token v2.0) dapat digunakan untuk otorisasi subjek. Namun, saat menggunakan klaim ini, aplikasi harus memastikan bahwa token dikeluarkan langsung untuk aplikasi dengan memvalidasi idtyp klaim opsional. Hanya token jenis app yang dapat diotorisasi dengan cara ini, karena token pengguna yang didelegasikan berpotensi diperoleh oleh entitas selain aplikasi.

Langkah berikutnya