Mengautentikasi pengguna untuk Zero Trust

Artikel ini membantu Anda, sebagai pengembang, untuk mempelajari praktik terbaik untuk mengautentikasi pengguna aplikasi Anda dalam pengembangan aplikasi Zero Trust. Selalu tingkatkan keamanan aplikasi Anda dengan prinsip Zero Trust dengan hak istimewa paling sedikit dan verifikasi secara eksplisit.

Token ID dalam autentikasi pengguna

Saat Anda memerlukan pengguna untuk mengautentikasi ke aplikasi Anda, daripada mengumpulkan nama pengguna dan kata sandi, aplikasi Anda dapat meminta token identitas (ID). Mengautentikasi pengguna melalui platform identitas Microsoft menghindari risiko keamanan yang muncul saat aplikasi Anda mempertahankan kredensial pengguna. Saat Anda meminta token ID, jika aktor jahat melanggar atau mengorbankan aplikasi Anda, tidak ada nama pengguna dan kata sandi yang sesuai di aplikasi Anda.

Token ID platform identitas Microsoft adalah bagian dari standar OpenID Koneksi (OIDC) yang menentukan token ID sebagai JSON Web Token (JWT). String panjang JWT terdiri dari tiga komponen:

1. Klaim header. Klaim header yang ada dalam token ID termasuk typ (klaim jenis), alg (algoritma untuk menandatangani token), dan kid (thumbprint untuk kunci publik untuk memvalidasi tanda tangan token).
2. Klaim payload. Payload atau isi (bagian tengah token web JSON) berisi serangkaian pasangan atribut nama. Standar mengharuskan ada klaim dengan iss (nama penerbit) yang masuk ke aplikasi yang mengeluarkan token ( audklaim audiens , atau ).
3. Tanda tangan. ID Microsoft Entra menghasilkan tanda tangan token yang dapat digunakan aplikasi untuk memvalidasi bahwa token tidak dimodifikasi dan Anda dapat mempercayainya.

Contoh token ID berikut menunjukkan informasi tentang pengguna dan mengonfirmasi autentikasi untuk menggunakan aplikasi.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

Token ID dalam manajemen akses

Untuk menerima ID aplikasi (klien) Anda, daftarkan aplikasi Anda dengan platform identitas Microsoft. Saat Anda menerima token dengan klaim audiens (aud) yang cocok dengan ID klien aplikasi Anda, pengguna yang diidentifikasi dalam token yang diautentikasi ke aplikasi Anda. Admin TI mungkin mengizinkan semua pengguna di penyewa menggunakan aplikasi Anda. Mereka mungkin mengizinkan grup yang penggunanya adalah anggota untuk menggunakan aplikasi Anda.

Jika Anda menerima token yang klaim audiensnya berbeda dari ID klien aplikasi Anda, segera tolak token. Pengguna tidak diautentikasi ke aplikasi Anda karena mereka masuk ke aplikasi lain. Selalu pastikan bahwa pengguna memiliki izin untuk menggunakan aplikasi Anda.

Detail klaim ini penting dalam autentikasi pengguna:

• Token web JSON valid hingga kedaluwarsa. Klaim (kedaluwarsa exp ) memberi tahu Anda ketika token kedaluwarsa. Jika waktu saat ini adalah sebelum waktu dalam exp klaim, token valid.
• Jangan anggap pengguna sebagai terautentikasi sebelum waktu yang ditentukan dalam nbf klaim (bukan sebelum waktunya). Waktu nbf dan exp token menentukan masa pakai token yang valid. Ketika waktu kedaluwarsa segera tiba, pastikan Anda mendapatkan token ID baru.
• sub (klaim subjek) adalah pengidentifikasi unik untuk pengguna aplikasi. Pengguna yang sama memiliki klaim yang berbeda sub untuk aplikasi lain. Jika Anda ingin menyimpan data untuk dikaitkan kembali ke pengguna dan mencegah penyerang membuat asosiasi tersebut, gunakan klaim subjek. Karena tidak mengekspos identitas Microsoft Entra pengguna, ini adalah cara paling privat untuk mengaitkan data ke pengguna. Klaim sub tidak dapat diubah.
• Jika Anda ingin berbagi informasi di beberapa aplikasi, gunakan kombinasi klaim ID penyewa (tid) dan ID objek (oid) yang unik untuk pengguna. ID penyewa gabungan dan ID objek tidak dapat diubah.
• Apa pun yang terjadi pada identitas individu, subklaim , , oiddan tid tetap tidak dapat diubah. Apa pun tentang pengguna dapat berubah dan Anda masih dapat membuat kunci data Anda mengidentifikasi pengguna berdasarkan subjek atau gabungan tid dan oid klaim.

Autentikasi dengan OIDC

Untuk menunjukkan autentikasi pengguna, mari kita lihat aplikasi yang menggunakan OIDC untuk mengautentikasi pengguna. Prinsip yang sama berlaku untuk aplikasi yang menggunakan Security Assertion Markup Language (SAML) atau WS-Federation.

Aplikasi mengautentikasi pengguna saat aplikasi meminta token ID dari platform identitas Microsoft. Beban kerja (aplikasi yang tidak memiliki pengguna yang ada melainkan berjalan sebagai layanan, proses latar belakang, daemon) melewati langkah ini.

Anda harus selalu diam-diam meminta token ini terlebih dahulu. Untuk memperoleh token secara diam-diam di Microsoft Authentication Libraries (MSAL), aplikasi Anda dapat dimulai dengan metode .AcquireTokenSilent Jika aplikasi Anda dapat mengautentikasi tanpa mengganggu pengguna, aplikasi akan menerima token ID yang diminta.

Jika platform identitas Microsoft tidak dapat menyelesaikan permintaan tanpa berinteraksi dengan pengguna, aplikasi Anda harus kembali ke metode MSALAcquireTokenInteractive. Untuk memperoleh token secara interaktif, lakukan permintaan dengan membuka permukaan web ke alamat di https://login.microsoftonline.com bawah domain.

Dari permukaan web ini, pengguna memiliki percakapan pribadi dengan platform identitas Microsoft. Aplikasi Anda tidak memiliki tampilan ke dalam percakapan ini, juga tidak memiliki kontrol percakapan apa pun. platform identitas Microsoft dapat meminta ID pengguna dan kata sandi, autentikasi multifaktor (MFA), autentikasi tanpa kata sandi, atau interaksi autentikasi lain yang dikonfigurasi admin TI atau pengguna.

Aplikasi Anda akan menerima token ID setelah pengguna melakukan langkah-langkah autentikasi yang diperlukan. Saat aplikasi menerima token, Anda dapat yakin bahwa platform identitas Microsoft mengautentikasi pengguna. Jika aplikasi Anda tidak menerima token ID, platform identitas Microsoft tidak mengautentikasi pengguna. Jangan izinkan pengguna yang tidak diaauthenticated untuk melanjutkan ke area aman aplikasi Anda.

Praktik terbaik bagi aplikasi untuk membuat sesi bagi pengguna setelah menerima token ID dari ID Microsoft Entra. Dalam token ID yang diterima aplikasi, klaim kedaluwarsa (exp) dengan tanda waktu Unix. Tanda waktu ini menentukan pada atau setelah waktu kedaluwarsa di mana aplikasi tidak boleh menerima JWT untuk diproses. Gunakan waktu kedaluwarsa token ini untuk mendorong masa pakai sesi pengguna Anda. Klaim ini exp memainkan peran penting dalam menjaga pengguna yang diverifikasi secara eksplisit di depan aplikasi dengan hak istimewa yang tepat dan untuk jumlah waktu yang tepat.

dukungan Akses Menyeluruh

Autentikasi akses menyeluruh (SSO) memungkinkan pengguna untuk masuk dengan satu set kredensial ke beberapa sistem perangkat lunak independen. SSO memungkinkan pengembang aplikasi untuk tidak mengharuskan pengguna untuk masuk ke setiap aplikasi secara terpisah dan berulang kali. Pada inti SSO, pengembang memastikan bahwa semua aplikasi di perangkat pengguna berbagi permukaan web yang mengautentikasi pengguna. Artefak di permukaan web (seperti status sesi dan cookie) setelah SSO drive autentikasi berhasil.

Seperti yang diilustrasikan dalam diagram berikut, kasus penggunaan permukaan web bersama yang paling sederhana adalah aplikasi yang berjalan di browser web (seperti Microsoft Edge, Google Chrome, Firefox, Safari). Tab browser berbagi status SSO.

Judul diagram: Browser web – kasus paling sederhana. Muncul di tengah atas diagram adalah bentuk cloud yang berisi ikon ID Microsoft Entra. Di bawah bentuk cloud adalah kotak. Koneksi bentuk cloud dan kotak adalah garis dengan panah di setiap ujungnya. Label kotak adalah "Biarkan saya tetap masuk, menyimpan cookie status SSO di seluruh pemanggilan." Di dalam kotak, di sisi kiri, adalah ikon yang terlihat seperti cookie. Di bawah cookie, keterangannya adalah "Percakapan privat dengan pengguna." Di bawah keterangan adalah ikon yang mewakili pengguna. Di sebelah kiri ketiga komponen ini, di dalam kotak, adalah kotak lain. Label kotak internal adalah "Tab." Di bawah label ada empat kotak persegi yang mewakili jendela browser di tab.

platform identitas Microsoft mengelola status SSO di browser tertentu kecuali pengguna memiliki browser yang berbeda yang terbuka pada perangkat yang sama. Pada Windows 10 dan yang lebih baru, platform identitas Microsoft secara asli mendukung SSO browser Microsoft Edge. Ketika pengguna masuk ke Windows, akomodasi di Google Chrome (melalui ekstensi akun Windows 10) dan di Mozilla Firefox v91+ (melalui pengaturan browser) memungkinkan setiap browser untuk berbagi status SSO Windows itu sendiri.

Seperti yang ditunjukkan pada diagram berikut, kasus penggunaan aplikasi asli lebih rumit.

Judul diagram: Aplikasi asli – browser yang disematkan – tanpa SSO. Muncul di tengah atas diagram adalah bentuk cloud yang berisi ikon ID Microsoft Entra. Di bagian bawah diagram ada empat kotak yang tersebar secara horizontal. Di sudut kanan bawah setiap kotak adalah ikon yang mewakili pengguna. Di dalam setiap kotak ada representasi jendela browser, termasuk ikon cookie dan ikon bola dunia. Koneksi masing-masing dari empat kotak ke bentuk cloud adalah garis dengan panah di setiap ujungnya.

Pendekatan broker autentikasi

Pola umum adalah agar setiap aplikasi asli memiliki WebView tersemat sendiri yang mencegahnya berpartisipasi dalam SSO. Untuk mengatasi skenario ini, MICROSOFT Entra ID menggunakan pendekatan broker autentikasi (broker autentikasi) untuk aplikasi asli seperti yang diilustrasikan dalam diagram berikut.

Judul diagram: Pendekatan broker autentikasi. Muncul di tengah atas diagram adalah bentuk cloud yang berisi ikon ID Microsoft Entra. Di bawah bentuk cloud adalah bentuk persegi panjang dengan label, Auth Broker. Bentuk persegi panjang berisi ikon cookie dan ikon bola dunia. Koneksi bentuk awan dan bentuk persegi panjang adalah garis dengan panah di setiap ujungnya. Di bagian bawah diagram ada empat kotak yang tersebar secara horizontal. Di sudut kanan bawah setiap kotak adalah ikon yang mewakili pengguna. Ikon di setiap kotak mewakili jendela browser. Koneksi masing-masing dari empat kotak ke bentuk persegi panjang adalah garis dengan panah di setiap ujungnya.

Dengan broker autentikasi di tempat, aplikasi mengirim permintaan autentikasi ke broker alih-alih langsung ke platform identitas Microsoft. Dengan cara ini, broker menjadi permukaan bersama untuk semua autentikasi pada perangkat.

Selain menyediakan permukaan bersama, broker autentikasi memberikan manfaat lain. Saat mengadopsi Zero Trust, perusahaan mungkin ingin aplikasi hanya berjalan dari perangkat yang dikelola perusahaan. Contoh manajemen perangkat perusahaan termasuk mobile Manajemen Perangkat (MDM) lengkap dan skenario di mana pengguna membawa perangkat mereka sendiri yang berpartisipasi dalam Mobile Application Management (MAM).

Secara desain, sistem operasi (OS) yang mendasar mengisolasi browser. Pengembang memerlukan koneksi yang lebih dekat dengan OS untuk memiliki akses penuh ke detail perangkat. Di Windows, broker autentikasi adalah Windows Web Account Manager (WAM). Di perangkat lain, broker autentikasi adalah aplikasi Microsoft Authenticator (untuk perangkat yang menjalankan iOS atau Android) atau Aplikasi Portal Perusahaan (untuk perangkat yang menjalankan Android). Aplikasi mengakses broker autentikasi dengan MSAL. Di Windows, aplikasi dapat mengakses WAM tanpa MSAL. Namun, MSAL adalah cara term mudah bagi aplikasi untuk mengakses broker autentikasi (terutama aplikasi yang tidak Platform Windows Universal aplikasi).

Broker autentikasi bekerja dalam kombinasi dengan MICROSOFT Entra ID untuk menggunakan Token Refresh Utama (PRT) yang mengurangi kebutuhan pengguna untuk mengautentikasi beberapa kali. PRT dapat menentukan apakah pengguna berada di perangkat terkelola. MICROSOFT Entra ID memerlukan broker autentikasi karena memperkenalkan token Bukti Kepemilikan, opsi yang lebih aman atas token pembawa yang lazim saat ini.

Langkah berikutnya

• Memecahkan masalah token akses Microsoft Entra: Memvalidasi token akses menjelaskan caranya, saat Anda memiliki token akses Microsoft Entra, Anda memverifikasi bahwa bidang tertentu cocok dengan rekaman.
• Tingkatkan ketahanan aplikasi autentikasi dan otorisasi, Anda mengembangkan aplikasi alamat seri yang menggunakan platform identitas Microsoft dan ID Microsoft Entra. Mereka termasuk panduan untuk aplikasi klien dan layanan yang bekerja atas nama aplikasi pengguna dan daemon yang masuk yang bekerja atas nama mereka sendiri. Mereka berisi praktik terbaik untuk menggunakan token dan memanggil sumber daya.
• Kustomisasi token menjelaskan informasi yang dapat Anda terima di token Microsoft Entra dan bagaimana Anda dapat menyesuaikan token.
• Mengonfigurasi klaim grup dan peran aplikasi dalam token menunjukkan kepada Anda cara mengonfigurasi aplikasi dengan definisi peran aplikasi dan menetapkan grup keamanan ke peran aplikasi.
• Membangun aplikasi yang mengamankan identitas melalui izin dan persetujuan memberikan gambaran umum tentang izin dan mengakses praktik terbaik.