Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Di platform identitas Microsoft, memahami izin dan persetujuan sangat penting untuk mengembangkan aplikasi aman yang memerlukan akses ke sumber daya yang dilindungi. Artikel ini memberikan gambaran umum tentang konsep dan skenario dasar yang terkait dengan izin dan persetujuan, membantu pengembang aplikasi meminta otorisasi yang diperlukan dari pengguna dan administrator. Dengan memahami konsep-konsep ini, Anda dapat memastikan aplikasi Anda hanya meminta akses yang mereka butuhkan, menumbuhkan kepercayaan dan keamanan.
Untuk mengakses sumber daya yang dilindungi seperti data email atau kalender, aplikasi Anda memerlukan otorisasi pemilik sumber daya. Pemilik sumber daya dapat menyetujui atau menolak permintaan aplikasi Anda. Memahami konsep dasar ini 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 bagaimana aplikasi Anda 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 diberikan pengguna kepada mereka 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. Saat diberikan melalui persetujuan, peran aplikasi mungkin juga 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 dapat mengakses apa pun yang tidak dapat diakses oleh pengguna yang masuk.
Misalnya, ambil aplikasi yang diberikan Files.Read.All izin yang didelegasikan atas nama pengguna. Aplikasi ini hanya 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 ini dapat mengakses data apa pun yang terkait dengan izin.
Misalnya, aplikasi yang diberikan izin aplikasi Microsoft Graph API 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 individual 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 sudah 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 diharuskan 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 untuk memberikan izin tanpa mengharuskan pengguna melihat permintaan persetujuan untuk serangkaian izin yang sama yang telah diotorisasi. Dengan cara ini, aplikasi yang telah diotorisasi tidak meminta pengguna untuk menyetujui izin. Pemilik sumber daya dapat melakukan pra-otorisasi aplikasi klien di portal Microsoft Azure atau dengan menggunakan PowerShell dan API seperti Microsoft Graph.
Dalam kebanyakan kasus, aplikasi yang dihadapi pelanggan di MICROSOFT Entra External ID semuanya akan memerlukan praautorisasi karena mereka ditujukan untuk pengguna yang bukan bagian dari organisasi dan yang tidak akan dapat menyetujui izin yang diminta oleh aplikasi. Praotorisasi memastikan bahwa pengguna ini dapat mengakses aplikasi tanpa dimintai persetujuan.
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 mungkin memberikan akses ke informasi sensitif. Contoh berbagai sistem otorisasi di Microsoft termasuk peran bawaan Microsoft Entra, Azure RBAC, Exchange RBAC, dan persetujuan khusus sumber daya Teams.