-
Notifications
You must be signed in to change notification settings - Fork 105
com.microsoft.aad.msal4j.MsalInteractionRequiredException: AADSTS65001 when calling acquireTokenSilently with IMAP/SMTP scopes #82
Comments
Hello @avayaappdev : Just to be clear, your basic situation is:
Did I understand your situation right? If so, I have a couple questions to try to find the root cause:
|
Hi @Avery-Dunn , yes right the situation happened as you described
so to be able to connect to mailbox with javax.mail on behalf of the signed in user. |
I don't have a javax.mail app to test with, but I was able to recreate the behavior where the token service seems to drop the 'https://outlook.com/' part of the requested scope and the 'has not consented' error when trying to refresh it. Scopes usually don't need the full resource ID (though I think this was more common in the past), but I'm not sure why the token service would drop it when returning the access token. My best guess is that it understands what you meant when you included 'https://outlook.com/ '. and is implying that 'IMAP.AccessAsUser.All' is enough and should get what you need. I noticed that the link you posted is under the category of 'legacy protocols' (and seems to use 'https://outlook.office.com/', rather than 'https://outlook.com/' as you've been writing here), so it's possible that these aren't the correct scopes to use anymore, or they only work for some specific scenarios. Try using 'https://graph.microsoft.com/IMAP.AccessAsUser.All' instead. This seems to be the equivalent 'delegated permission' that you'd be able to find in the 'API Permissions' tab of your Azure app, and for me at least I was able to refresh it without getting that 'has not consented message'. However, as I said I wasn't able to test the javax.mail side of things so I'm not sure if it'll work there, nor do I know what configuration might need to be changed. |
I've already used the https://graph.microsoft.com/IMAP.AccessAsUser.All scope during my trials
and I think that is expected because I'm not accessing the mailbox resource using Microsoft Graph API, I'm connecting using IMAP and SMTP legacy protocols and authenticating them using OAuth. also, I've found that if the resource identifier is omitted in the scope parameter, the resource is assumed to be Microsoft Graph by default as stated in the the below document. |
Could you describe your scenario a bit? Is there a reason you can't just use Graph? I don't have much experience programmatically sending email or using the scopes that Azure AD provides, but most of the documentation I've found (and the one you've linked) seems to be saying that these are mostly deprecated in favor of Microsoft Graph. Also I've noticed you've written "https://outlook.com/" as the resource before the actual scopes. Is there a reason for that? The documentation you linked says it should be "https://outlook.office.com/". And for the 'user has not consented' error message, the reason for that may be that the Azure AD app is not be remembering that the user has consented to them. If you go to the 'API Permissions' tab of your app registration, are any of the IMAP/SMTP permissions showing up as having been consented to? For me, only the time I consented to the Microsoft Graph version seems to have registered in the Azure app, and I can't find any non-Graph versions of those scopes as an option when trying to add new permissions: |
I can't use Graph API because the system I'm currently working on is already using IMAP and SMTP protocols for mail scenarios and migrating to Microsoft Graph API will take time, also I couldn't see a direct saying in Microsoft documentations that the old permissions are really deprecated. |
I also couldn't find anything directly saying that the old permissions are deprecated, it's just something I assumed since the IMAP.AccessAsUser.All permission in the app registration is only available for Graph, the link you posted is under a section called 'Legacy Protocols', and most of the docs I've been able to find assume you're using Graph (even the original version of that 'Legacy Protocols' doc assumed Graph). I asked some people with more knowledge of Outlook/Graph and they recommended checking out the Microsoft Graph SDK (here is the Java sdk) and the Outlook mail REST API to see if they could help make accessing the mailboxes easier. |
Good day, I currently face the same issue in that I need to migrate a service that talks to IMAP from Basic Auth to OAuth, without switching to Graph. From what I understand, it is possible to retrieve a token for a daemon type application. However, this token cannot be reliably used to access IMAP with javax.mail. Did you find a solution since? Or is the solution truly to fully migrate to Graph instead? |
I'm currently facing an issue with Java MSAL implementing the OAuth 2.0 authorization code flow when attempting
to get a new access token using the refresh token stored in token cache by calling the library method acquireTokenSilently method and that only happen when passed silent parameters has any one of the below scopes which I need to authenticate IMAP/SMTP access to mailbox using OAuth as mentioned in the Microsoft document below
https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth
That caused the below Error
Although when fetching the authorization code used to acquire an access token for the first time I signed in with my Global administrator account that registered the app on Microsoft Azure Active Directory and granted all the permissions requested
by my registered app
but when the IMAP/SMTP scopes are as below without specifying the resource identifier outlook.office365.com or outlook.com
the acquireTokenSilently method worked successfully and returned an access token.
but when trying to use that returned token from acquireTokenSilently method to access the mailbox using javax.mail library 1.6.1
That returned an Authentication Error
Any help much appreciated.
The text was updated successfully, but these errors were encountered: