Large organization start leveraging the Graph API to provide integrations between their third party applications and Office 365. In such companies it is common to delegate the development of integrations from the central IT organization to other business units.
The current app-only permission priviledges are not appropriate for such types of setups since there is currently no way to limit the permissions for that app to a specific resource in Office 365. This makes such use cases impossible to implement.

As an example we could consider SharePoint Online. Whever a business unit has to develop a daemon tool that exchanges data between their third party system and a SharePoint Online resource (a subset of site collections, an individual site, even a list), this cannot be done without granting them access to all SharePoint resources of that organization. This is because app-only permissions for an application are considered as an "all or nothing" type of permission for that application.

You could take a similar example with Exchange Online resources. Also in that specific case there is no way to limit the permissions to individual mailboxes.

These are the ways to implement such type of scenarios:
- Fallback to the "classic" api and authentication model (in SharePoint addin development). This has the drawback of not leveraging the Graph API. Furthermore, this type of application is unaware of conditional access mechanisms, making it a possible security thread for such organizations.
- Create a cloud identity and an application with delegated permissions. Grant to this cloud identity the necessary rights to the desired resource and then authenticate against the environment with username, password + app. This has the disadvantage of higher complexity and the need to use cloud identities, since federated identities are not working in such a scenario. The usage of a service account is also not ideal

Would be awesome to obtain a way to limit such types of applications on resource level. In theory, you could also only request an "admin consent" in case an application really requires access to all SharePoint Online resources. For such types of scenario an admin consent is not necessary required as long we are ensuring the application has access to specific resources only.

I would like to be able to fully migrate my AD users to the cloud, so that when I use them to log into an AzureAD Joined Machine, the whoami CMD properly returns AzureAD\fristnamelastname. Right now there are hidden attributes accociated with the previously AD synced user, that causes the whoami CMD to return DOMAIN\username. This is preventing cloud migrations.

Response I received suggesting that I contact this team.

"This a known gap, that we're reviewing. Even though you have migrated the user from AD to Azure AD, the onprem SamAccountName is still intact on the user object, among other on-prem AD attributes. As a result, Azure AD picks those details and shows domain/user instead of AzureAD/user. This attribute cannot be modified or cleared through Graph APIs at this point, so there's no way to change the behavior

Please file a UserVoice suggestion on MS Graph for this so that our teams can get the feedback and prioritize it as needed"

Impossible to get members of Azure AD group with expanded 'manager' property in one request.
for example:
https://graph.windows.net/<tenantid>/directoryObjects/<groupid>/members/?api-version=1.6&$expand=manager

we gets the following response:
{"code":"Request_UnsupportedQuery","message":{"lang":"en","value":"An unsupported query was observed. Please ensure you query does not navigate across multiple reference-properties."}

I suppose reason of such response is clear. and current workaround is the following:
1) Get group members
2) for each five members(using OData batch) get manager
But this way make us do a lot of requests to Azure AD and we expect performance degradation here.

We develop multi tenant application which access Azure AD of all our customers and it's painfully slow process to get group members' managers....

According to Microsoft support there is no good way how to it...

https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/entity-and-complex-type-reference#user-entity shows that we can GET, POST and PATCH the "otherMails" attribute of a user object. otherMails is described as "A list of additional email addresses for the user", which makes it sound like the user's email aliases. However, if you set this attribute, then look at the user in the Office365 Admin Center or Powershell, you see it's actually the "Alternate Email Address" attribute: i.e. the contact address required for admin accounts. In the Graph API the attribute that lists the email aliases is "proxyAddresses" and this is read-only (i.e. only supports GET). It's been explained to me by Microsoft support that the proxyAddresses attribute is owned by Exchange Online and there's currently no programmatic access to the attribute except via Powershell. But we could really use an API for this.

Worth noting that the AAD Graph API's current capability looks like a bug. You can programmatically set 'otherMails' (aka Alternate Mail Address) with multiple values, but if you then look at that attribute in the O365 admin UI or via Powershell (set-msoluser), it only accepts and uses a single value.

This has been around since at least 2013 (see https://social.msdn.microsoft.com/Forums/azure/en-US/8bd82025-ef07-479d-9c7a-da0f9b4a75fd/setmsoluser-alternateemailaddresses-issue?forum=WindowsAzureAD)