Open mmcalynnproof opened 1 month ago
Hi @mmcalynnproof, thanks for following up here!
Are you using an admin consent URI? If so it sends you the tenant id when consent is granted (or denied) and you can track the status. Full details of the parameters are documented here: Admin consent on the Microsoft identity platform. Does that work in your scenario, or are using a different technique to get admin consent?
Thanks! David
@davidchesnut yes we're using the consent URL but not with the {tenant} path as in that link, https://login.microsoftonline.com/organizations/adminconsent?client_id={our_id}.
So you're suggesting we set up the redirect_uri parameter to point to a path in our application and have it store the tenant value sent to that URL? I'd be wary that since this would be a public unauthenticated path it would be vulnerable to bad actors sending junk data to that path we couldn't trust. It'll only be able to track registrations from the time we get the change pushed to production also.
Is there anything built into Microsoft services for a given Azure application to view the Tenants that have consented to it so far? If not then I'll take a look at the redirect option.
Hi @mmcalynnproof,
From checking with the team on this more, there doesn't seem to be any way to get this information as the add-in publisher. One suggestion here is to implement in your add-in a message to the user when consent is missing. You'll get an error from MSAL indicating consent is not granted. Then you can show a message informing the user that the admin needs to consent, and maybe provide the admin consent URL.
Hope this helps, David
Thanks for following up on that @davidchesnut. Yep we've got that kind of handling in place so end users know to reach out to their admins and admin gets guidance on step to take.
"You'll get an error from MSAL indicating consent is not granted"
Can a confirmed list of how to detect this for varying accounts and platforms be provided? I originally was trying to detect this specific consent failure but found what was returned inconsistent. The error returned had '.errorCode'as 'invalid_grant' for general users in OWA. Then for admin accounts I saw '.errorCode' come back as 'consent_required' for admin accounts. Then in New Windows Outlook 'consent_required' was inside an error message property instead of '.errorCode'. And Old Windows Outlook and New Outlook for Mac returned little detail beyond an error name 'InteractionRequiredAuthError'. Didn't document what Android and iOS returned.
So rather than try and figure out all possible scenarios here and what they return we opted to instead output the consent recommendation for any error encountered during token retrieval.
@davidchesnut this is marked as needs author feedback but I've commented on latest response and asked a question on how to idenitfy the MSAL consent errors due to observing them vary across different platforms.
"You'll get an error from MSAL indicating consent is not granted"
Can a confirmed list of how to detect this for varying accounts and platforms be provided?
Hi @mmcalynnproof,
Sorry about that. There's a complete list of error codes here, many of which involve various consent scenarios. Microsoft Entra authentication and authorization error codes. However, I need to amend my earlier response. In general MSAL will prompt the user to consent if consent was not already granted. Are you seeing that the user is not prompted for consent? Or are they prompted to consent, but not granting consent?
Thanks! David
Hi, I was directed here from Add-in Community call.
To support add-in Nested App Authentication in our add-in we've created an Azure Application with the required permissions and put out a bulletin for consumers of the add-in that they need have an admin for their O365 tenant go to the application's consent page and accept the permissions.
This information was sent out a few months ago. Now that the legacy tokens are being turned off we noticed a few cases where tenants were reporting their add-in wasn't working and it was that they hadn't granted consent for the permissions.
To aid us in making the rollout of Nested App Authentication smoother I'm requesting information on how we could identify which tenants have already consented to our NAA Azure Application. That way we can then proactively reach out to those tenants who haven't and prompt them to accept the permissions.