If your application can’t use OAuth 2.0 authorization flow as a user-interactive flow, such as RPA(Robotic Process Automation) or observation system for some event, it is good that use OAuth 2.0 authorization flow with grant_type parameter as password or client_credentials.
This article describes how to use properly these two cases.
・User-interactive type and user-less type flow
An app which observes events of a system or executes some function, RPA also have to access to some resource. And when access to some resources, an app has to be authorized to access some resources by the resource owner.
In case of an app to access a resource managed by Microsoft Graph, an app can use Microsoft Graph API which solves these processes.
Microsoft Graph API provides several features such as exposing the Office 365 API, resources management the Azure Active Directory. And provides the authentication feature that is a fundamental feature. The authentication feature of Microsoft Graph API supports WS-Fed, SAML, OAuth 2.0, and OpenID Connect.
Particularly OAuth 2.0 is programmable flow, so this article describes how to control the OAuth 2.0 flow of Microsoft Graph API.
The OAuth 2.0 Authorization Framework defines user-interaction type flow( ‘authorization_code’ grant flow and ‘implicit’ grant flow), and user-less type flows(‘client_credentials’ grant flow and ‘password’ grant flow).
So ‘client_credentials’ grant flow and ‘password’ grant flow are usable to an app such as observes events of a system, executes some function or RPA.
OAuth 2.0 defines a mechanism that an app how to access to resources of a resource owner as below.
1. An app requests for an authorization server to acquire code which represents a resource owner is log in. Meanwhile, an authorization server returns a confirmation form to an app for a user allowing access to user resources. An app waits for a user to allow.
2. When a user allows access to user resources, an authorization server returns a code to an app, then an app sends a code to a resource server.
3. Resource server issues access token to an app for an app to access the resource of the owner.
The ‘client_credentials’ grant flow and the ‘password’ grant flow skips ‘1’ step and ‘2’ step Instead, an app send credential to the resource server on step ‘2’.
・Grant type client_credentials flow
An app uses a credential to acquire a token that Microsoft Graph API provided has information which an account and resource that the account can access, maintenance or search. The ‘client_credentials’ grant flow uses credential for an impersonated user which is kept at Microsoft Azure Active Directory application.
>>The article ‘Create Azure Active Directory application‘
Use the Application (client) ID which Azure Active Directory application issues as an account when using the ‘client_cledential’ grant flow. In ‘The OAuth 2.0 Authorization Framework’, it says ‘Entity’. For this entity, the Azure Active Directory application issues the Client secret as a password of this account.
The entity in Microsoft Graph API has default access permission to several resources. Reading basic information of Azure Active Directory accounts and so on.
>>The article ‘How to set attributes of Azure Active Directory application for impersonated users‘
・Grant type password flow
The ‘password’ grant flow asserts the user explicitly, the ‘client_credentials’ grant flow uses an impersonated user. So when using ‘password’ grant_type flow, Microsoft Graph API returns an access_token that has several permissions depend on the login user.
For Example, add delegate permit ‘User.Read.All’ to the Azure Active Directory application.
Then acquire two access tokens both the ‘client_credentials’ grant type and the ‘password’ grant type with the Postman. At the last, send a post request to URL ‘https://graph.microsoft.com/v1.0/users’ with an access token which is acquired.
>>The article ‘How to set attributes of Azure Active Directory application for impersonated users‘
key : username and value : user account@domain name. key : password and value : password of user account. key : client_id and value : copy from Application (client) ID of Azure portal. key : client _secretand and value : copy from where kept place at when client secret issued. key : grant_type and value : put 'password'.
The access token using the ‘client_credentials’ grant type will return fail, and the ‘password’ grant type will return users list of the domain.
Thus, please check the chart below.
| Microsoft account | Organization account | ||
| Microsoft Graph authentication grant type | |||
| client_credentials*1 | password | client_credentials | |
| Azure Active Directory application API permissions type | |||
| Application permission | Application permission | Delegate permission | Application permission*2 |
| Using individual Azure Active Directory applications per feature. | Use to access Microsoft Graph resource or executing common features that sending a mail, post a message to the Microsoft Teams and so on. | Use to access resources of Azure Active Directory user or executing a feature that Admin Consent Required. | Use to access Microsoft Graph resource or executing common features that sending a mail, post a message to the Microsoft Teams and so on. |
*1:Can’t use password grant type flow for the Microsoft Account.
*2:Set maximum API permissions to the Azure Active Directory application, then use minimum scope of the feature when request token.
No responses yet