Gambaran umum izin dan persetujuan di platform identitas Microsoft
Untuk mengakses sumber daya yang dilindungi seperti email atau data kalender, aplikasi Anda memerlukan otorisasi pemilik sumber daya. Pemilik sumber daya dapat menyetujui atau menolak permintaan aplikasi Anda. Memahami konsep dasar ini akan membantu Anda membangun aplikasi yang lebih aman dan dapat dipercaya yang hanya meminta akses yang mereka butuhkan, ketika mereka membutuhkannya, dari pengguna dan administrator.
Skenario akses
Sebagai pengembang aplikasi, Anda harus mengidentifikasi cara aplikasi Anda akan mengakses data. Aplikasi dapat menggunakan akses yang didelegasikan, bertindak atas nama pengguna yang masuk, atau akses khusus aplikasi, hanya bertindak sebagai identitas aplikasi sendiri.
Akses yang didelegasikan (akses atas nama pengguna)
Dalam skenario akses ini, pengguna telah masuk ke aplikasi klien. Aplikasi klien mengakses sumber daya atas nama pengguna. Akses yang didelegasikan memerlukan izin yang didelegasikan. Baik klien dan pengguna harus diotorisasi secara terpisah untuk membuat permintaan. Untuk informasi selengkapnya tentang skenario akses yang didelegasikan, lihat skenario akses yang didelegasikan.
Untuk aplikasi klien, izin yang didelegasikan dengan benar harus diberikan. Izin yang didelegasikan juga dapat disebut sebagai cakupan. Cakupan adalah izin untuk sumber daya tertentu yang mewakili apa yang dapat diakses aplikasi klien atas nama pengguna. Untuk informasi selengkapnya tentang cakupan, lihat cakupan dan izin.
Untuk pengguna, otorisasi bergantung pada hak istimewa yang telah diberikan pengguna untuk mengakses sumber daya. Misalnya, pengguna dapat diberi wewenang untuk mengakses sumber daya direktori oleh kontrol akses berbasis peran (RBAC) Microsoft Entra atau untuk mengakses sumber daya email dan kalender oleh Exchange Online RBAC. Untuk informasi selengkapnya tentang RBAC untuk aplikasi, lihat RBAC untuk aplikasi.
Akses khusus aplikasi (Akses tanpa pengguna)
Dalam skenario akses ini, aplikasi bertindak sendiri tanpa ada pengguna yang masuk. Akses aplikasi digunakan dalam skenario seperti otomatisasi, dan pencadangan. Skenario ini mencakup aplikasi yang berjalan sebagai layanan latar belakang atau daemon. Skenario ini cocok digunakan ketika tidak diinginkan untuk memiliki pengguna tertentu yang masuk, atau ketika data yang diperlukan tidak dapat dicakup untuk satu pengguna. Untuk informasi selengkapnya tentang skenario akses khusus aplikasi, lihat Akses khusus aplikasi.
Akses khusus aplikasi menggunakan peran aplikasi alih-alih cakupan yang didelegasikan. Ketika diberikan melalui persetujuan, peran aplikasi juga dapat disebut izin aplikasi. Aplikasi klien harus diberikan izin aplikasi yang sesuai dari aplikasi sumber daya yang dipanggilnya. Setelah diberikan, aplikasi klien dapat mengakses data yang diminta. Untuk informasi selengkapnya tentang menetapkan peran aplikasi ke aplikasi klien, lihat Menetapkan peran aplikasi ke aplikasi.
Jenis izin
Izin yang didelegasikan digunakan dalam skenario akses yang didelegasikan. Izin yang didelegasikan adalah izin yang memungkinkan aplikasi bertindak atas nama pengguna. Aplikasi tidak akan pernah dapat mengakses apa pun yang tidak dapat diakses oleh pengguna yang masuk.
Misalnya, ambil aplikasi yang telah diberikan Files.Read.All izin yang didelegasikan atas nama pengguna. Aplikasi hanya akan dapat membaca file yang dapat diakses pengguna secara pribadi.
Izin aplikasi, juga dikenal sebagai peran aplikasi, digunakan dalam skenario akses khusus aplikasi, tanpa ada pengguna yang masuk. Aplikasi akan dapat mengakses data apa pun yang terkait dengan izin tersebut.
Misalnya, aplikasi yang diberikan izin Files.Read.All aplikasi Microsoft Graph API akan dapat membaca file apa pun di penyewa menggunakan Microsoft Graph. Secara umum, hanya administrator atau pemilik perwakilan layanan API yang dapat menyetujui izin aplikasi yang diekspos oleh API tersebut.
Perbandingan izin yang didelegasikan dan aplikasi
| Jenis izin | Izin yang didelegasikan | Izin aplikasi |
|---|---|---|
| Jenis aplikasi | Web / Seluler / aplikasi satu halaman (SPA) | Web / Daemon |
| Konteks akses | Mendapatkan akses atas nama pengguna | Mendapatkan akses tanpa pengguna |
| Siapa yang dapat menyetujui | - Pengguna dapat menyetujui data mereka - Admin dapat menyetujui semua pengguna |
Hanya admin yang dapat menyetujui |
| Metode persetujuan | - Statis: daftar yang dikonfigurasi pada pendaftaran aplikasi - Dinamis: meminta izin individu saat masuk |
- HANYA Statis: daftar yang dikonfigurasi pada pendaftaran aplikasi |
| Nama lainnya | -Cakupan - Cakupan izin OAuth2 |
- Peran aplikasi - Izin khusus aplikasi |
| Hasil persetujuan (khusus untuk Microsoft Graph) | OAuth2PermissionGrant | appRoleAssignment |
Persetujuan
Salah satu cara agar aplikasi diberikan izin adalah melalui persetujuan. Persetujuan adalah proses saat pengguna atau admin mengotorisasi aplikasi untuk mengakses sumber daya yang dilindungi. Misalnya, saat pengguna mencoba masuk ke aplikasi untuk pertama kalinya, aplikasi dapat meminta izin untuk melihat profil pengguna dan membaca konten kotak surat pengguna. Pengguna melihat daftar izin yang diminta aplikasi melalui permintaan persetujuan. Skenario lain di mana pengguna mungkin melihat permintaan persetujuan meliputi:
- Ketika persetujuan yang diberikan sebelumnya dicabut.
- Ketika aplikasi dikodekan untuk secara khusus meminta persetujuan selama masuk.
- Ketika aplikasi menggunakan persetujuan dinamis untuk meminta izin baru sesuai kebutuhan pada waktu proses.
Detail utama dari permintaan persetujuan adalah daftar izin yang diperlukan aplikasi dan informasi penerbit. Untuk informasi selengkapnya tentang permintaan persetujuan dan pengalaman persetujuan untuk admin dan pengguna akhir, lihat pengalaman persetujuan aplikasi.
Persetujuan pengguna
Persetujuan pengguna terjadi saat pengguna mencoba masuk ke aplikasi. Pengguna memberikan kredensial masuk mereka, yang diperiksa untuk menentukan apakah persetujuan telah diberikan. Jika tidak ada catatan persetujuan pengguna atau admin sebelumnya untuk izin yang diperlukan, pengguna akan diperlihatkan permintaan persetujuan, dan diminta untuk memberikan izin yang diminta kepada aplikasi. Admin mungkin diminta untuk memberikan persetujuan atas nama pengguna.
Persetujuan administrator
Tergantung pada izin yang mereka butuhkan, beberapa aplikasi mungkin memerlukan administrator untuk menjadi orang yang memberikan persetujuan. Misalnya, izin aplikasi dan banyak izin yang didelegasikan hak istimewa tinggi hanya dapat disetujui oleh administrator.
Administrator dapat memberikan persetujuan untuk diri mereka sendiri atau untuk seluruh organisasi. Untuk informasi selengkapnya tentang persetujuan pengguna dan admin, lihat gambaran umum persetujuan pengguna dan admin.
Permintaan autentikasi diminta untuk persetujuan admin jika persetujuan tidak diberikan dan jika salah satu izin hak istimewa tinggi tersebut diminta.
Permintaan izin yang berisi cakupan aplikasi kustom tidak dianggap sebagai hak istimewa tinggi dan dengan demikian, permintaan tersebut tidak memerlukan persetujuan admin.
Praotorisasi
Praotorisasi memungkinkan pemilik aplikasi sumber daya memberikan persetujuan tanpa mengharuskan pengguna melihat permintaan persetujuan untuk kumpulan izin yang sama yang telah diotorisasi sebelumnya. Dengan cara ini, aplikasi yang telah diotorisasi sebelumnya tidak akan meminta pengguna untuk menyetujui izin. Pemilik sumber daya dapat melakukan praotorisasi aplikasi klien di portal Microsoft Azure atau dengan menggunakan PowerShell dan API, seperti Microsoft Graph.
Sistem otorisasi lainnya
Kerangka kerja persetujuan hanyalah satu cara aplikasi atau pengguna dapat diotorisasi untuk mengakses sumber daya yang dilindungi. Admin harus mengetahui sistem otorisasi lain yang dapat memberikan akses ke informasi sensitif. Contoh berbagai sistem otorisasi di Microsoft termasuk peran bawaan Entra, Azure RBAC, Exchange RBAC, dan persetujuan khusus sumber daya Teams.