Requesting permissions that require administrative consent
Requesting admin consent in advance
最好是admin提前處理好consent，這樣user就不需要單獨申請了
Your best application permissions strategy is to declare in advance all of the permissions that your app may need or will eventually request when you register your app. You don't have to request all permissions at the same time but, after you declare all of the permissions that your app may need, admins can select Grant admin consent for in your app's configuration in the tenant to display a dialog similar to this example.
Delegated access example – OneDrive via Microsoft Graph
Consider the following example:
Alice wants to use a client app to open a file protected by a resource API, Microsoft Graph. For user authorization, the OneDrive service will check whether the file is stored in Alice’s drive. If it’s stored in another user’s drive, then OneDrive will deny Alice’s request as unauthorized, since Alice doesn't have the right to read other users’ drives.
For client app authorization, OneDrive will check whether the client making the call has been granted the Files.Read scope on behalf of the signed-in user. In this case, the signed-in user is Alice. If Files.Read hasn’t been granted to the app for Alice, then OneDrive will also fail the request.
| GET /drives/{id}/files/{id} | Client app granted Files.Read scope for Alice |
Client app not granted Files.Read scope for Alice |
|---|---|---|
| The document is in Alice’s OneDrive. | 200 – Access granted. | 403 - Unauthorized. Alice (or her admin) hasn’t allowed this client to read her files. |
| The document is in another user’s OneDrive*. | 403 - Unauthorized. Alice doesn’t have rights to read this file. Even though the client has been granted Files.Read it should be denied when acting on Alice’s behalf. |
403 – Unauthorized. Alice doesn’t have rights to read this file, and the client isn’t allowed to read files she has access to either. |
The example given is simplified to illustrate delegated authorization. The production OneDrive service supports many other access scenarios, such as shared files.
What's https://graph.microsoft.com/.default?
https://graph.microsoft.com/.default is a special scope in Microsoft Graph API that is used to request all permissions that have been configured in the application's registration manifest for the Microsoft Graph API. It is used when requesting an access token with application permissions, as opposed to user or delegated permissions.
When you register an application in the Azure portal and request permissions for Microsoft Graph API, you specify the type of permissions you want to use: application, user, or both. If you choose application permissions, you can use the .default scope to request all the permissions that have been configured in the application's registration manifest for the Microsoft Graph API.
azure application permissions vs delegated permission
In Azure Active Directory (Azure AD), there are two types of permissions that can be granted to an application: application permissions and delegated permissions.
Application permissions are also known as "app-only" permissions. These are permissions that are granted to the application itself, rather than to a user or group. They allow the application to act on its own behalf, without requiring a user to be signed in. Examples of application permissions might include "read all users' full profiles" or "write all groups".
Delegated permissions, on the other hand, are also known as "user-delegated" permissions. These are permissions that are granted to an application on behalf of a signed-in user. They allow the application to act as that user, and perform actions on their behalf. Examples of delegated permissions might include "read the signed-in user's profile" or "send mail on behalf of the user".
In general, application permissions should be used when an application needs to access resources or perform actions that don't require user context or are related to administration of the tenant. Delegated permissions should be used when an application needs to access resources or perform actions on behalf of a user, with that user's consent.
It's important to note that not all permissions can be granted as both application and delegated permissions. Some permissions are only available as one or the other, depending on the API being accessed. Additionally, the permissions that an application can request depend on the configuration of the API and the permissions that the requesting application is authorized to use.
So the application permission and delegated permission both use the ClientId and ClientSecret?
Yes, both application permissions and delegated permissions require a registered Azure AD application, which has a unique client ID and client secret (or a certificate, in the case of app-only authentication). The difference is in how the authentication and authorization process works.
For application permissions, the Azure AD app authenticates and authorizes itself to access a resource, such as a Microsoft Graph API, using its own client credentials. This means that the app is acting on its own behalf, rather than on behalf of a user.
For delegated permissions, the Azure AD app is granted permission to access a resource, such as a Microsoft Graph API, on behalf of a user. In this case, the user must grant consent for the app to access their resources, and the app uses an access token obtained through the OAuth 2.0 authorization code flow or another flow that involves user interaction to access the resource.
Could you give a sample about how to use delegated permission to get all users under the same TenantId in c#?
Here's an example of how to use delegated permissions to get a list of all users in the same tenant as the signed-in user:
// Set the delegated permission scope required to read user profiles.
string[] scopes = new[] { "User.Read" };
// Create a new instance of the Microsoft Graph client using the signed-in user's access token.
var graphClient = new GraphServiceClient(new DelegateAuthenticationProvider(async (requestMessage) =>
{
// Get the current access token for the signed-in user.
string accessToken = await GetAccessTokenForSignedInUserAsync(scopes);
// Add the access token to the HTTP Authorization header.
requestMessage.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
}));
// Get a list of all users in the tenant.
var users = await graphClient.Users.Request().GetAsync();
foreach (var user in users)
{
Console.WriteLine(user.DisplayName);
}In this example, the DelegateAuthenticationProvider is used to get an access token for the signed-in user with the necessary User.Read delegated permission scope. The GraphServiceClient is then initialized with this access token, allowing it to make requests on behalf of the signed-in user.
The Users.Request().GetAsync() method call is used to retrieve a list of all users in the tenant. Finally, a foreach loop is used to iterate through the users and print out their display names.
Note that in order for delegated permissions to work, the signed-in user must have appropriate permissions to access the resources requested by the application. In this case, the signed-in user must have permission to read user profiles in order to retrieve a list of all users in the tenant.
Access scenarios
As an application developer, you must identify how your application will access data. The application can use delegated access, acting on behalf of a signed-in user, or app-only access, acting only as the application's own identity.
Delegated access (access on behalf of a user)
In this access scenario, a user has signed into a client application. The client application accesses the resource on behalf of the user. Delegated access requires delegated permissions. Both the client and the user must be authorized separately to make the request. For more information about the delegated access scenario, see delegated access scenario.
For the client app, the correct delegated permissions must be granted. Delegated permissions can also be referred to as scopes. Scopes are permissions for a given resource that represent what a client application can access on behalf of the user. For more information about scopes, see scopes and permissions.
For the user, the authorization relies on the privileges that the user has been granted for them to access the resource. For example, the user could be authorized to access directory resources by Azure Active Directory (Azure AD) role-based access control (RBAC) or to access mail and calendar resources by Exchange Online RBAC. For more information on RBAC for applications, see RBAC for applications.
Delegated access (access on behalf of a user)
In this access scenario, a user has signed into a client application and the client application calls Microsoft Graph on behalf of the user. Both the client and the user must be authorized to make the request.
Delegated access requires delegated permissions, also referred to as scopes. Scopes are permissions that are exposed by a given resource and they represent the operations that an app can perform on behalf of a user.
Because both the app and the user must be authorized to make the request, the resource grants the client app the delegated permissions, for the client app to access data on behalf of the specified user. For the user, the actions that they can perform on the resource rely on the permissions that they have to access the resource. For example, the user might be the owner of the resource, or they might be assigned a particular role through a role-based access control system (RBAC) such as Azure AD RBAC.
How does delegated access work?
The most important thing to remember about delegated access is that both your client app and the signed-in user need to be properly authorized. Granting a scope isn't enough. If either the client app doesn’t have the right scope, or the user doesn’t have sufficient rights to read or modify the resource, then the call will fail.
- Client app authorization - Client apps are authorized by granting scopes. When a client app is granted a scope by a user or admin to access some resource, that grant will be recorded in Azure AD. All delegated access tokens that are requested by the client to access the resource on behalf of the relevant user will then contain those scopes’ claim values in the
scpclaim. The resource app checks this claim to determine whether the client app has been granted the correct scope for the call. - User authorization - Users are authorized by the resource you’re calling. Resource apps may use one or more systems for user authorization, such as role-based access control, ownership/membership relationships, access control lists, or other checks. For example, Azure AD checks that a user has been assigned to an app management or general admin role before allowing them to delete an organization’s applications, but also allows all users to delete applications that they own. Similarly, SharePoint Online service checks that a user has appropriate owner or reader rights over a file before allowing that user to open it.
Introduction to permissions and consent
Types of permissions
Delegated permissions are used in the delegated access scenario. They're permissions that allow the application to act on a user's behalf. The application will never be able to access anything the signed in user themselves couldn't access.
For example, imagine an application that has been granted the Files.Read.All delegated permission on behalf of Tom, the user. The application will only be able to read files that Tom can personally access.
Application permissions, sometimes called app roles are used in the app-only access scenario, without a signed-in user present. The application will be able to access any data that the permission is associated with. For example, an application granted the Files.Read.All application permission will be able to read any file in the tenant. Only an administrator or owner of the service principal can consent to application permissions.
There are other ways in which applications can be granted authorization for app-only access. For example, an application can be assigned an Azure AD RBAC role.
User permissions