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.

Currently it is possible (if you have permission) to view BitLocker recovery keys on the "Device" page of the Azure Active Directory portal.

It is also possible to view Device information through the API or through Microsoft Graph, but this does not include the BitLocker recovery information.

A programmatic way to view this data would be incredibly useful for creating a secure backup of the recovery keys.

Another use case, which is what I was hoping to achieve, is to have users in the field encrypt data with their BitLocker key and then send a CD containing the encrypted data back to the main office where it needs to be decrypted and added to our systems. This is not possible unless the upload system in our main office has programmatic access to the recovery keys.

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)