Want to develop application to access resources with Microsoft Graph API’s then please enroll for this course
Authentication and authorization basics:
What you’ll learn
- Learn how to authenticate and work with permissions to securely access data through Microsoft Graph.
- Learn how to add and register an application using the App registrations experience in the Azure portal.
- How to get access on behalf of a user.
- How to get access without a user.
Course Content
- Introduction –> 1 lecture • 2min.
- Overview and basics –> 1 lecture • 5min.
- Get access on behalf of a user –> 4 lectures • 29min.
- Thank You and Congratulations!!! –> 1 lecture • 1min.
Requirements
Authentication and authorization basics:
To call Microsoft Graph, your app must acquire an access token from the Microsoft identity platform. The access token contains information about your app and the permissions it has to access the resources and APIs available through Microsoft Graph. To get an access token, your app must be registered with the Microsoft identity platform and be authorized by either a user or an administrator to access the Microsoft Graph resources it needs.
Register your app with the Microsoft identity platform
Before your app can get a token from the Microsoft identity platform, it must be registered in the Azure portal. Registration integrates your app with the Microsoft identity platform and establishes the information that it uses to get tokens, including:
- Application ID: A unique identifier assigned by the Microsoft identity platform.
- Redirect URI/URL: One or more endpoints at which your app will receive responses from the Microsoft identity platform. (For native and mobile apps, the URI is assigned by the Microsoft identity platform.)
- Client secret: A password or a public/private key pair that your app uses to authenticate with the Microsoft identity platform. (Not needed for native or mobile apps.)
Microsoft Graph permissions
Microsoft Graph exposes granular permissions that control the access that apps have to resources, like users, groups, and mail. As a developer, you decide which Microsoft Graph permissions to request for your app. When a user signs in to your app they, or, in some cases, an administrator, are given a chance to consent to these permissions. If the user consents, your app is given access to the resources and APIs that it has requested. For apps that access resources and APIs without a signed-in user, permissions can be pre-consented to by an administrator when the app is installed.
Delegated and application permissions
Microsoft Graph has two types of permissions:
- Delegated permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph. Some delegated permissions can be consented by non-administrative users, but some higher-privileged permissions require administrator consent.
- Application permissions are used by apps that run without a signed-in user present. For example, apps that run as background services or daemons. Application permissions can only be consented by an administrator.
Effective permissions
Effective permissions are the permissions that your app has when making requests to Microsoft Graph. The effective permissions are determined by a combination of the Microsoft Graph permissions that you granted to the app and the privileges of the signed-in user or the calling app. Within organizations, the policy or membership in one or more roles determine the privileges of the signed-in user or an app. It’s important to understand the difference between the delegated and application permissions your app has and its effective permissions when making calls to Microsoft Graph.
Effective permissions in delegated versus application-only permission scenarios
- For delegated permissions, the effective permissions of your app are the least-privileged intersection of the delegated permissions the app has been granted (by consent) and the privileges of the currently signed-in user. Your app can never have more privileges than the signed-in user.Suppose that your app has been granted the User.ReadWrite.All delegated permission and calls the Update user API. This permission nominally grants your app permission to read and update the profile of every user in an organization. However, because of effective permissions, the following restrictions apply to the privileges of the signed-in user:
- If the signed-in user is a global administrator, your app can update the profile of every user in the organization.
- If the signed-in user isn’t in an administrator role, your app can update only the profile of the signed-in user. It won’t update the profiles of other users in the organization because the signed-in user doesn’t have those privileges.
- For application permissions, the effective permissions of your app are the full level of privileges implied by the permission. For example, an app that has the User.ReadWrite.All application permission can update the profile of every user in the organization.