Access to my Office 365 third-party app for external user : "a User account is not registered for the account"

Question

In my third-party web application of Office 365, I want to have access to the contacts, events and emails of all the users from the organizations who installed my app. The thing is I don't want that all these users have to grant me access, I just want one
admin of the org to grant access for my app and then be able to retrieve the data I need for all the users.
To test for one organization, I logged in as the admin and proceed to the Oauth2 authentication to retrieve the access token and in the first request (the GET one to retrieve an authorization code) i add the parameter
prompt=admin_consent.
With this access token, I can access the data (emails, contact, event) of the admin
for instance for the contacts
uri: https://outlook.office365.com/ews/odata/Users(adminemail)/Contacts
but not the data of the other users of this org with this uri
uri: https://outlook.office365.com/ews/odata/Users(useremail)/Contacts
The only thing I can do is retrieve an access token for each user but it supposed that each user has to authorize the access to the app but it's very cumbersome. So, i don't see what enables the parameter prompt=admin_consent and how to use it. Does anybody
know what it does?
And my question is: how can I do to access the data of all the users of one organization when the access has been granted by one admin?
Thank you!

Answer 1

    
This was answered on StackOverflow by Dushyant Gill.  http://stackoverflow.com/questions/25316175/access-to-my-office-365-third-party-app-for-external-user-a-user-account-is-n/25316678#25316678
You are sending the OAuth request to a tenant specific endpoint of Azure AD. Note the {key_provided} part of your Url - that part represents the tenantid or a registered domain name of an Azure AD tenant. Azure AD throws this error is the user signing in
is not a user in that tenant.
Multi-tenant applications like yours have two options:
Perform home realm discovery yourself and send the SSO request to the correct tenant-specific endpoint of Azure AD: when a new Azure AD organization signs-up for your application, record its tenant ID, and registered domain names. On your login page, ask
the user for their email and try to discover what Org they belong to using the suffix the email.
Use the common endpoint of Azure AD. Instead of the {key_provided} part of the URL, use 'common'. In this case Azure AD will determine the user's tenant and sign-in the user. The token that your application will receive will still be from the user's tenant
(iss claim).
2 is more convenient for apps. However #1 has an advantage when the user's Organization has customized their sign-in page with the company logo etc - in the case of #1 the user will directly be taken to the customized and familiar sign-in page.
I recommend a combination of the two: try determining the user's organization and sending them to the tenant specific SSO endpoint. If you're not able to - send them to the common endpoint.