I'm developing an application that I registered with Microsoft at apps.dev.microsoft.com to use their new "converged" OAuth2 flow documented at https://azure.microsoft.com/en-us/documentation/articles/active-directory-v2-protocols-oauth-code/.
I am requesting authorization for scope user.read. Specifically, this is the authorize URL:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=77ebf38a-23aa-4006-b947-aae863964ba7&redirect_uri=https%3A%2F%2Flocalhost%3A44302%2Fazure_connection%2Fcallback&response_type=code&scope=user.read
I expect this to work 100% of the time as I'm only asking for the user.read scope, which is documented at https://graph.microsoft.io/en-us/docs/authorization/permission_scopes as not requiring delegation. However, for my corporate (aka organizational) account, when I login to the authorize URL I get the error AADSTS90093: Does not have access to consent. My corp organizational account is a regular user role in our AAD.
Every other authorize request works as expected. I've tested this with other organizational accounts who are admins, contributors, and regular users in other Azure accounts I have. I've tested this with "MSA" accounts (outlook.com, hotmail.com, other Live-registered accounts) too.
The only differences in accounts that I can think of:
The account that fails is an Office 365 account. (Every other test I've done with an organizational account has been me manually entering the account in AAD in "the old portal".)
The account that fails is the account under which I registered the app on apps.dev.microsoft.com (Oh the irony!)
Anyone encountering this? Do you see anything wrong with the authorize URL or the authorization scope? Is there some setting in AAD or in Office 365 that could prevent third-party OAuth access to "myself"?