Bagikan melalui

Mengelola token untuk Zero Trust

  • Artikel

Dalam pengembangan aplikasi Zero Trust, penting untuk secara khusus menentukan niat aplikasi Anda dan persyaratan akses sumber dayanya. Aplikasi Anda hanya boleh meminta akses yang diperlukan untuk berfungsi seperti yang dimaksudkan. Artikel ini membantu Anda, sebagai pengembang, untuk membangun keamanan ke dalam aplikasi Anda dengan token ID, token akses, dan token keamanan yang dapat diterima aplikasi Anda dari platform identitas Microsoft.

Pastikan aplikasi Anda mematuhi prinsip Zero Trust dengan hak istimewa paling sedikit dan mencegah penggunaan dengan cara yang membahayakan niat Anda. Batasi akses pengguna dengan Just-In-Time dan Just-Enough-Access (JIT/JEA), kebijakan adaptif berbasis risiko, dan perlindungan data. Pisahkan bagian sensitif dan canggih aplikasi Anda, yang hanya menyediakan akses pengguna yang berwenang ke area ini. Batasi pengguna yang dapat menggunakan aplikasi Anda dan kemampuan yang mereka miliki di aplikasi Anda.

Bangun hak istimewa paling sedikit ke dalam cara aplikasi Anda mengelola token ID yang diterimanya dari platform identitas Microsoft. Informasi dalam Token ID memungkinkan Anda memverifikasi bahwa pengguna adalah siapa yang mereka klaim. Pengguna atau organisasi mereka mungkin menentukan kondisi autentikasi seperti menyediakan MFA, menggunakan perangkat terkelola, dan berada di lokasi yang benar.

Permudah pelanggan Anda untuk mengelola otorisasi ke aplikasi Anda. Kurangi overhead provisi pengguna mereka dan kebutuhan akan proses manual. Provisi pengguna otomatis memungkinkan admin TI mengotomatiskan pembuatan, pemeliharaan, dan penghapusan identitas pengguna di penyimpanan identitas target. Pelanggan Anda dapat mendasarkan otomatisasi pada perubahan pada pengguna dan grup dengan provisi aplikasi atau provisi berbasis SDM di ID Microsoft Entra.

Menggunakan klaim token di aplikasi Anda

Gunakan klaim dalam token ID untuk UX di dalam aplikasi Anda, sebagai kunci dalam database, dan menyediakan akses ke aplikasi klien. Token ID adalah ekstensi inti yang dilakukan OpenID Koneksi (OIDC) ke OAuth 2.0. Aplikasi Anda dapat menerima token ID bersama atau alih-alih token akses.

Dalam pola standar untuk otorisasi token keamanan, token ID yang dikeluarkan memungkinkan aplikasi untuk menerima informasi tentang pengguna. Jangan gunakan token ID sebagai proses otorisasi untuk mengakses sumber daya. Server otorisasi mengeluarkan token ID yang berisi klaim dengan informasi pengguna yang menyertakan yang berikut ini.

  • Klaim audiens (aud) adalah ID klien aplikasi Anda. Hanya terima token untuk ID klien API Anda.
  • Klaim tid adalah ID penyewa yang mengeluarkan token. Klaim oid adalah nilai yang tidak dapat diubah yang secara unik mengidentifikasi pengguna. Gunakan kombinasi unik klaim tid dan oid sebagai kunci saat Anda perlu mengaitkan data dengan pengguna. Anda dapat menggunakan nilai klaim ini untuk menyambungkan data Anda kembali ke ID pengguna di ID Microsoft Entra.
  • Klaim sub adalah nilai yang tidak dapat diubah yang secara unik identitas pengguna. Klaim subjek juga unik untuk aplikasi Anda. Jika Anda menggunakan sub klaim untuk mengaitkan data dengan pengguna, tidak mungkin untuk pergi dari data Anda dan menghubungkannya dengan pengguna di ID Microsoft Entra.

Aplikasi Anda dapat menggunakan openid cakupan untuk meminta token ID dari platform identitas Microsoft. Standar OIDC mengatur openid cakupan bersama dengan format dan konten token ID. OIDC menentukan cakupan ini:

  • openid Gunakan cakupan untuk memasukkan pengguna dan menambahkan sub klaim ke token ID. Cakupan ini menyediakan ID pengguna yang unik untuk aplikasi dan pengguna dan memanggil titik akhir UserInfo.
  • email Cakupan menambahkan klaim yang email berisi alamat email pengguna ke token ID.
  • profile Cakupan menambahkan klaim dengan atribut profil dasar pengguna (nama, nama pengguna) ke token ID.
  • offline_access Cakupan memungkinkan aplikasi mengakses data pengguna bahkan ketika pengguna tidak ada.

Microsoft Authentication Library (MSAL) selalu menambahkan openid, email, dan profile cakupan ke setiap permintaan token. Akibatnya, MSAL selalu mengembalikan token ID dan token akses pada setiap panggilan ke AcquireTokenSilent atau AcquireTokenInteractive. MSAL selalu meminta offline_access cakupan. platform identitas Microsoft selalu mengembalikan offline_access cakupan bahkan ketika aplikasi yang meminta tidak menentukan offline_access cakupan.

Microsoft menggunakan standar OAuth2 untuk mengeluarkan token akses. Standar OAuth2 mengatakan bahwa Anda menerima token, tetapi tidak menentukan format token atau apa yang perlu ada dalam token. Saat aplikasi Anda perlu mengakses sumber daya yang dilindungi MICROSOFT Entra ID, aplikasi tersebut harus menggunakan cakupan yang ditentukan sumber daya.

Misalnya, Microsoft Graph menentukan User.Read cakupan yang mengotorisasi aplikasi untuk mengakses profil pengguna lengkap pengguna saat ini dan nama penyewa. Microsoft Graph menentukan izin di seluruh berbagai fungsionalitas yang tersedia di API tersebut.

Setelah otorisasi, platform identitas Microsoft mengembalikan token akses ke aplikasi Anda. Saat Anda memanggil sumber daya, aplikasi Anda menyediakan token ini sebagai bagian dari header otorisasi permintaan HTTP ke API.

Mengelola masa pakai token

Aplikasi dapat membuat sesi untuk pengguna setelah autentikasi berhasil diselesaikan dengan ID Microsoft Entra. Manajemen sesi pengguna mendorong seberapa sering pengguna membutuhkan autentikasi ulang. Perannya dalam menjaga pengguna yang diverifikasi secara eksplisit di depan aplikasi dengan hak istimewa yang tepat dan untuk jumlah waktu yang tepat sangat penting. Masa pakai sesi harus didasarkan pada exp klaim dalam token ID. Klaim exp adalah waktu kedaluwarsa token ID dan waktu setelah itu Anda tidak dapat lagi menggunakan token untuk mengautentikasi pengguna.

Selalu hormati masa pakai token seperti yang disediakan dalam respons token untuk token akses atau exp klaim dalam token ID. Kondisi yang mengatur masa pakai token dapat mencakup frekuensi masuk untuk perusahaan. Aplikasi Anda tidak dapat mengonfigurasi masa pakai token. Anda tidak dapat meminta masa pakai token.

Secara umum, token harus valid dan tidak kedaluwarsa. Klaim audiens (aud) harus sesuai dengan ID klien Anda. Pastikan token berasal dari penerbit tepercaya. Jika Anda memiliki API multipenyewa, Anda dapat memilih untuk memfilter sehingga hanya penyewa tertentu yang dapat memanggil API Anda. Pastikan Anda memberlakukan masa pakai token. nbf Periksa klaim (tidak sebelumnya) dan (kedaluwarsa exp ) untuk memastikan waktu saat ini berada dalam dua nilai klaim tersebut.

Jangan bertujuan untuk masa pakai sesi yang sangat panjang atau pendek. Biarkan masa pakai token ID yang diberikan mendorong keputusan ini. Menjaga sesi aplikasi Anda tetap aktif di luar validitas token melanggar aturan, kebijakan, dan kekhawatiran yang mendorong admin TI untuk menetapkan durasi validitas token untuk mencegah akses yang tidak sah. Sesi singkat menurunkan pengalaman pengguna dan tidak selalu meningkatkan postur keamanan. Kerangka kerja populer seperti ASP.NET memungkinkan Anda mengatur sesi dan batas waktu cookie dari waktu kedaluwarsa token ID Microsoft Entra ID. Mengikuti waktu kedaluwarsa token idP memastikan bahwa sesi pengguna Anda tidak pernah lebih lama dari kebijakan yang ditentukan penyedia identitas.

Cache dan refresh token

Ingatlah untuk menyimpan token dengan tepat. MSAL secara otomatis menyimpan token tetapi token memiliki masa pakai. Gunakan token melalui panjang penuh masa pakainya dan cache dengan tepat. Jika Anda berulang kali meminta token yang sama, pembatasan menyebabkan aplikasi Anda menjadi kurang responsif. Jika aplikasi Anda menyalahgunakan penerbitan token, waktu yang diperlukan untuk mengeluarkan token baru ke aplikasi Anda akan diperpanjang.

Pustaka MSAL mengelola detail protokol OAuth2 termasuk mekanisme token penyegaran. Jika Anda tidak menggunakan MSAL, pastikan pustaka pilihan Anda memanfaatkan token refresh yang efektif.

Saat klien Anda memperoleh token akses untuk mengakses sumber daya yang dilindungi, klien menerima token refresh. Gunakan token refresh untuk mendapatkan pasangan token akses/refresh baru setelah token akses saat ini kedaluwarsa. Gunakan token refresh untuk memperoleh token akses tambahan untuk sumber daya lain. Token refresh terikat pada kombinasi pengguna dan klien (bukan ke sumber daya atau penyewa). Anda dapat menggunakan token refresh untuk memperoleh token akses di semua kombinasi sumber daya dan penyewa tempat aplikasi Anda memiliki izin.

Mengelola kesalahan dan bug token

Aplikasi Anda tidak boleh mencoba memvalidasi, mendekode, memeriksa, menginterpretasikan, atau memeriksa konten token akses. Operasi ini sepenuhnya menjadi tanggung jawab API sumber daya. Jika aplikasi Anda mencoba memeriksa konten token akses, kemungkinan besar aplikasi Anda berhenti saat platform identitas Microsoft mengeluarkan token terenkripsi.

Jarang, panggilan untuk mengambil token dapat gagal karena masalah seperti jaringan, infrastruktur, atau kegagalan atau pemadaman layanan autentikasi. Tingkatkan ketahanan pengalaman autentikasi dalam aplikasi Anda jika kegagalan akuisisi token terjadi dengan mengikuti praktik terbaik berikut:

  • Cache secara lokal dan token aman dengan enkripsi.
  • Jangan meneruskan artefak keamanan seperti token di sekitar saluran yang tidak aman.
  • Memahami dan bertindak berdasarkan pengecualian dan respons layanan dari IdP.

Pengembang sering memiliki pertanyaan tentang mencari token di dalam untuk men-debug masalah seperti menerima kesalahan 401 dari memanggil sumber daya. Karena token yang lebih terenkripsi mencegah Anda melihat ke dalam token akses, Anda perlu menemukan alternatif untuk melihat token akses di dalamnya. Untuk penelusuran kesalahan, respons token yang berisi token akses menyediakan informasi yang Anda butuhkan.

Dalam kode Anda, periksa kelas kesalahan daripada kasus kesalahan individual. Misalnya, tangani interaksi pengguna yang diperlukan daripada kesalahan individual saat sistem tidak memberikan izin. Karena Anda mungkin melewatkan kasus individu tersebut, lebih baik memeriksa pengklasifikasi seperti interaksi pengguna daripada menggali kode kesalahan individual.

Anda mungkin perlu kembali ke AcquireTokenInteractive dan memberikan tantangan klaim yang AcquireTokenSilent diperlukan panggilan. Melakukannya memastikan manajemen permintaan interaktif yang efektif.

Langkah berikutnya