Mengelola token untuk Zero Trust

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. Hanya sediakan 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 MFA, perangkat terkelola, dan lokasi yang benar.

Permudah pelanggan Anda untuk mengelola otorisasi ke aplikasi Anda. Kurangi overhead pembuatan dan konfigurasi pengguna serta 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 pengalaman pengguna di dalam aplikasi Anda sebagai kunci dalam database. Berikan akses ke aplikasi klien. Token ID adalah ekstensi inti yang dilakukan OpenID Connect (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 tentang informasi pengguna, yang termasuk hal-hal 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. Gunakan 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 yang dimaksud juga unik untuk aplikasi Anda. Jika Anda menggunakan klaim sub untuk mengaitkan data dengan pengguna, tidak mungkin untuk menghubungkan data Anda dengan pengguna di Microsoft Entra ID.

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

  • Gunakan openid ruang lingkup untuk login pengguna dan menambahkan klaim sub ke token ID. Cakupan ini menyediakan ID pengguna yang unik untuk aplikasi dan pengguna dan memanggil titik akhir UserInfo.
  • email Cakupan menambahkan klaim berisi email alamat email pengguna ke ID token.
  • 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 scope. 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 lengkap pengguna saat ini dan nama tenant. 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 memerlukan autentikasi berulang. 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, pastikan bahwa token valid dan tidak kedaluwarsa. Klaim audiens (aud) harus cocok 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. Periksa klaim nbf (tidak sebelum) dan klaim exp (kedaluwarsa) untuk memastikan waktu saat ini berada dalam nilai dari kedua 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 waktu habis sesi dan cookie dari waktu kedaluwarsa token ID Microsoft Entra. Ikuti batas waktu kedaluwarsa token penyedia identitas untuk memastikan bahwa sesi pengguna Anda tidak pernah lebih lama dari kebijakan yang ditetapkan oleh penyedia identitas.

Cache dan refresh token

Ingatlah untuk menyimpan token dengan tepat. MSAL secara otomatis menyimpan token tetapi token memiliki masa pakai. Gunakan token sepanjang masa berlakunya dan cache token tersebut dengan tepat. Jika Anda berulang kali meminta token yang sama, pembatasan (throttling) menyebabkan aplikasi Anda menjadi kurang responsif. Jika aplikasi Anda menyalahgunakan penerbitan token, waktu 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 pada setiap kombinasi sumber daya dan penyewa di mana 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 gagal karena masalah seperti kegagalan atau pemadaman layanan jaringan, infrastruktur, atau autentikasi. Tingkatkan ketahanan pengalaman autentikasi dalam aplikasi Anda jika kegagalan akuisisi token terjadi dengan mengikuti praktik terbaik berikut:

  • Cache token secara lokal dan amankan dengan enkripsi.
  • Jangan menyebarkan artefak keamanan seperti token melalui saluran yang tidak aman.
  • Memahami dan bertindak berdasarkan pengecualian dan respons layanan dari penyedia identitas.

Pengembang sering memiliki pertanyaan tentang memeriksa isi token untuk melakukan debug masalah seperti menerima kesalahan 401 saat mengakses 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 debugging, 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 klaim tantangan yang diperlukan oleh panggilan AcquireTokenSilent. Melakukannya memastikan manajemen permintaan interaktif yang efektif.

Langkah berikutnya

  • Last updated on