Announcing OAuth 2.0 support for IMAP and SMTP AUTH protocols in Exchange Online
Published Apr 30 2020 08:00 AM 228K Views

Ever since we announced our intention to disable Basic Authentication in Exchange Online we said that we would add Modern Auth (OAuth 2.0) support for the IMAP, POP and SMTP AUTH protocols.

Today, we’re excited to announce the availability of OAuth 2.0 authentication for IMAP and SMTP AUTH protocols to Exchange Online mailboxes. This feature announcement is for interactive applications to enable OAuth for IMAP and SMTP.

For additional information about non-interactive applications, please see our blog post Announcing OAuth 2.0 Client Credentials Flow support for POP and IMAP protocols in Exchange Online.

Application developers who have built apps that send, read or otherwise process email using these protocols will be able to implement secure, modern authentication experiences for their users. This functionality is built on top of Microsoft Identity platform (v2.0) and supports access to email of Microsoft 365 (formerly Office 365) users.

Detailed step-by-step instructions for authenticating to IMAP and SMTP AUTH protocols using OAuth are now available for you to get started.

What’s supported?

With this release, apps can use one of the following OAuth flows to authorize and get access tokens on behalf of a user.

  1. OAuth2 authorization code flow
  2. OAuth2 Device authorization grant flow

Follow these detailed step-by-step instructions to implement OAuth 2.0 authentication if your in-house application needs to access IMAP and SMTP AUTH protocols in Exchange Online, or work with your vendor to update any apps or clients that you use that could be impacted.

The Exchange Team

101 Comments
Brass Contributor

Are there any popular IMAP Clients already supporting OAUTH authentication? Thanks Christian

Copper Contributor

Thunderbird 77 supports IMAP using OAuth2 on Office 365. See https://bugzilla.mozilla.org/show_bug.cgi?id=1528136 for more details.

Iron Contributor

I’ve read the linked documentation several times now, and as far as I can tell, there’s no way for automated (non-interactive) applications or daemons to access Exchange Online mailboxes using IMAP with OAuth. Or am I missing something? The issue is requesting tokens. The doc suggests that only two OAuth flows - Authorization Code Flow and Device Authorization Grant Flow - are supported by IMAP. Neither of which appears to be suitable for non-interactive auth. The doc also states that “OAuth access to IMAP, POP, SMTP AUTH protocols via OAuth2 client credentials grant flow is not supported” and that is the flow recommended by Microsoft for server to server or non-interactive apps! The suggestion is to use Graph API “if your application needs persistent access to all mailboxes in an tenant”. But we just need individual non-interactive applications to have access to specific mailboxes via IMAP using OAuth. Or can we use any OAuth flow via the MSAL client libraries, including ROPC or Windows Integrated Authentication that should support non-interactive auth? We have many non-interactive apps that use IMAP to programmatically access EXO mailboxes. If not, how are these apps supposed to migrate to OAuth?

Copper Contributor

@stukeyExactly my question also. 

Copper Contributor

@The_Exchange_Team it would be great to clarify this in your blog post. We have discussions again that we can get rid of app registrations with this news. But for applications with non-interactive users, like deamons or reporting tools, it is still needed to go through an app registration with application permission, right?

You need to create an app registration anyway as far as I understand.

Copper Contributor

I have waited this for some months.

Copper Contributor

@The_Exchange_Team, thank you for the update! I'll be using IMAP and SMTP to implement some functionality and this is definitely helpful.

I tried the steps from the provided instruction, but it didn't work. I've submitted my finding to the StackOverflow question, can someone from your team have a look at this?

Copper Contributor

@stukey Exactly my question also. 

@The_Exchange_Team : can you clarify this for us in blog post?

Iron Contributor

@The_Exchange_Team @Greg Taylor - EXCHANGE Please can you respond to the above questions from myself and many others regarding support for non-interactive apps?

This feature announcement is for interactive applications to enable OAuth for IMAP, POP, SMTP. At this time, there are no plans to enable IMAP, POP, SMTP OAuth for non-interactive applications using client credentials flow.

Steel Contributor

I'm afraid of how many multi-function copiers and legacy applications this is going to take down. A very real and major concern once OAuth 2 is the only way to send email through the Exchange Online SMTP servers! :sad:

@Jared Pickerell - we haven't said when SMTP AUTH will require OAuth. It's going to take much longer, we know that. 

Copper Contributor

When will Outlook.com support this for Imap and Pop?

Copper Contributor

To be more precise, when will the consumer version of Outlook.com support modern auth/oauth2 for syncing 0365 accounts to personal accounts via the sync accounts option?

Steel Contributor

@Greg Taylor - EXCHANGE, I didn't read closely enough so appreciate you clearing that up for me! A big sigh of relief! Thanks!

Brass Contributor

With this (April 30th ’20) release of OAuth2 support for IMAP and SMTP, Sivaprakash-MSFT commented on Stackoverflow: “IMAP, SMTP scopes are targeted for Exchange resource and not Graph” and “... we will only allow Exchange resource URLs to work and don’t have plans to enable Graph resource URLs”. But under AAD API permissions, SMTP.Send only appears as selectable when the Microsoft Graph API is selected. If I select the Exchange API (under Supported legacy APIs or via Enterprise apps), there is no selectable SMTP.Send or IMAP.AccessAsUser.All. So if my app uses a scope of outlook.office365.com/SMTP.Send, or outlook.com/SMTP.Send there isn't a matching permission in AD except under graph.microsoft.com/ (apparently the wrong API…).

 

I gather from Stackoverflow posts that there is confusion over:

- the URL prefix (e.g. https://outlook.office.com/) of a requested scope such as https://outlook.office.com/SMTP.Send as specified in an app

- the API selected in AAD to allow that scope (e.g. Microsoft Graph or Exchange)

 

Perhaps someone in the Exchange Team could clarify.

Tnx

Brass Contributor

Is it possible to achieve this through Powershell? Currently most of the internal automations use powershell and it was simple to send email reports using Powershell.

Brass Contributor

I guess the issue is one of delegation: how the resource owner can delegate permission to access his/her resource to others (e.g. a website). It goes to the heart of MSFT's (and Google's) wish to manage delegated authentication and authorisation properly.

The mechanics of sending are, as you, say, realisable using Powershell, but the authentication of Powershell jobs by creation of a service principal is not  dissimilar from OAUTH2's resource owner.

 

Or perhaps I misunderstand your comment.

 

Brass Contributor

MSAL libraries have been announced for:

- .NET (unsurprisingly)

- JavaScript and TypeScript superset framworks

- Android

- iOS and MacOS

- Java (for Windows, macOS and Linux)

- Python (Windows, macOS, and Linux)

 

But lack of PHP support for SMTP AUTH with Oauth2 will have a devastating impact on the zillions of backend apps that currently use Basic Authentication.

As an example, the hugely popular PHPMailer used, I guess, on every Linux / Apache server in the universe supports Oauth2 for access to Gmail, Yahoo and the older MSFT consumer mail platforms and (with some difficulty) for the Azure AD for developers (v1.0) endpoint but not for the MSFT identity platform (v2.0) endpoint: when pointed at V2.0 in order to use SMTP AUTH for outbound access to O365 Exchange Online, it will fail, even with the obvious changes to ‘authorise’ and ‘token’ endpoint URLs and to scopes (aka permissions).

 

And SMTP AUTH support has only and understandably been announced for the V2.0 endpoint so there is no way to regress via V1.0, even as a stopgap.

 

Deprecating Basic Authentication is a sensible move, but Oauth2 is FAR more complex to work with, and since MSFT wants everyone to be on O365 (and why not?), MSAL support for PHP would be appreciated. All the backend PHP apps that need to use Oauth2 to access O365 services will need rework, and it seems sensible integrate MSAL instead of direct calls to the V2.0 endpoint.

Copper Contributor

Is the Oauth2 Resource Owner Password Grant flow supported for SMTP/IMAP? I can't seem to find any information about this.

Brass Contributor

My construing of MSFT’s announcement is that Resource Owner Password Credentials Grant (per RFC6749 section-4.3) was not supported since they stated specifically that the more secure Client Credentials Grant (per RFC6749 section-4.4) was not supported. 

RFC6749 section-4.3 reads as if the authentication stage is essentially Basic Authentication – something MSFT wants to eradicate.

 

Perhaps MSFT team will comment

Copper Contributor

Meanwhile, I have done some testing (send an email with SMTP using an access token received with ROPC as described here https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc). The implementation seems to work for now.

The flow does seem to use some form of Basic Authentication to fetch the access token, but the SMTP protocol is done with Oauth2.

 

Is it expected that this approach will also be made unusable once Basic Authentication for SMTP, IMAP, etc. is disabled?

It would be very useful for me if this solution would still be supported.

@The_Exchange_Team 

Brass Contributor

Indeed - that was my take also. Since the authentication stage is really grafted in the front of Oauth2's authorisation process, I was assuming that any Basic Authentication currently supported would eventually be removed.

But this is not my area and I suspect you know much more about it than I do!

Copper Contributor

@Greg Taylor - EXCHANGE Can you confirm if IMAP/SMTP via OAuth will be allowed without disabling Security Defaults as described in this post https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-d... I want to confirm a fresh O365 user/organization won't have to do anything special with their O365/Azure AD configuration to allow an OAuth IMAP connection.

 

Thanks,

-Joe

@tDimache - ROPC will work. But, it’s not recommended and should only be used for apps that have a high trust relationship with the user.

 

 @jkemp1011005 - will double check but I believe IMAP/POP will just work with OAuth by default for new orgs.  

Brass Contributor

@Greg Taylor - EXCHANGE Given the zillions of server-based Contact forms extant,  many of which will simply use MSFT services to mail the form onwards to the website host, it will be intriguing to know to what grant type they  will be converted. The sensitive bits - e.g. MSFT 365 credentials of the resource owner -  are hidden behind PHP or similar and the user of the form does not present any credentials of their own. This all sounds like ROPC ... 

Copper Contributor

 

@Greg Taylor - EXCHANGE 

@jkemp1011005 

 

Our implementation experience is that with older Exchange accounts the OAuth SMTP authentication works, but with newer accounts it does not, due to an SMTP security flag that is now default to on vs before it was off. 

 

https://answers.microsoft.com/en-us/msoffice/forum/all/office-365-smtp-authentication-failing-even-w...

 

This is a big friction point and blocker for our application. Essentially, customers use OAuth to grant SMTP and IMAP for our application with admin consent (when applicable) and we still can't auth with SMTP. This means we are still forced to have them perform basic auth. 

 

Can you all please prioritize this, we have thousands of Office 365 customers wanting this ability, especially so, given the deadlines on deprecating basic auth (which is understandable). 

 

There will be huge amounts of friction and support if we have to guide customers and their IT staff through obscure settings in the admin ... for which we couldn't even find ... and if we have to explain powershell to our end user customers ... this isn't going to happen. We can't be expected to take on that support. If OAuth SMTP scope grant is given and there is admin consent (when applicable) ... we should be able to authenticate as a delegated app.

Copper Contributor

@The_Exchange_Team Thanks a lot for the blog. I'm using JavaMail to connect with IMAP and SMTP to implement some functionality. 

I tried the steps from the provided instruction and add properties mentioned in JavaMail Article  I always get Authenticate Failed. Saw some post to add scope https://outlook.office365.com/IMAP.AccessAsUser.All but they are no longer available which indeed made me to add scope https://graph.microsoft.com/IMAP.AccessAsUser.All , but it didn't help always ended up with Authenticate Failed issue. I've submitted my finding to the StackOverFlow question

can someone from your team have a look at this? Can we still able to add scope https://outlook.office365.com/IMAP.AccessAsUser.All ? Any body did it certainly ? Or it's an permission issue with me only

 

Thanks,

Vinayak

Copper Contributor

Has Auth 2.0 been released to Oracle.  We use IMAP EBS 12.1.3 for email notifications and haven't heard anything from Oracle.

@Pat_Truby - that's a question for Oracle isn't it? 

Copper Contributor

Greg

As of June they do not have anything from Microsoft, at least that is what is mentioned in Metalink.  I have opened an SR with Oracle was just hoping if someone knew if code was delivered. Just trying to get information, my management is pushing me.

@Pat_Truby - the dev docs are all public. Not sure what they are expecting to be delivered as such. They need to update their code to work with our service, following the guidance we have publicly published.  

Microsoft

@Anthony_Gentile_FUB 

Hi Anthony

 

Thanks you for your comment. New organisations onboarding to Exchange Online now have SMTP AUTH disabled by default for their tenants. This was taken with security in mind, with the understanding that there may be friction. Given that this is a protocol-based setting, OAuth will not work either unless the protocol is enabled for the mailbox.

As part of onboarding to use your app, they will need to either turn on the protocol for the mailbox or for their entire tenant. You can direct them to the documentation explaining how to do this here:

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client...

Copper Contributor

@Sean_Stevenson 

 

That is unfortunate to hear. It will cause SaaS companies, such as ours, to bear the brunt of this poor, non obvious experience mutual customers, which in turn will cause us to recommend to them other providers such as gsuite. Ours is an industry of hundreds of thousands real estate agents and their respective teams.

 

Right now the solution for this friction is very technical. We are left to explain to customers that they need to do something complicated in PowerShell or get involved with their IT staff. Why? Why can't this be a setting in the admin that we can point and link to?

 

Also why is this SMTP setting also affecting the IMAP protocol authentication?

Copper Contributor

@The_Exchange_Team @Greg Taylor - EXCHANGE 
Hi,
As mentioned here https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-i...

Oauth2 support for imap and smtp protocols is not supported for outlook.com customers. What about other domains like hotmail.com, msn.com etc?

Can you please tell if Oauth2 is supported for hotmail.com, msn.com etc? or is it only supported for Office365 users?
Also can office365 user have domain with outlook.com?

Microsoft

@Anthony_Gentile_FUB 

 

The new Exchange Admin Center is currently being rolled out and we do plan to add the setting there in the future. 

 

Re: SMTP and IMAP, IMAP is the protocol used to retrieve emails from a mailbox and is paired with the SMTP (AUTH) protocol which is responsible for submitting emails to be sent from the mailbox.  

Brass Contributor

Tnx SeanMSFT

For access to 365 Exchange, MSFT has variously announced:

 

- “We want your help in getting users to move away from apps that use Basic Authentication, to apps that use Modern Authentication” [MSFT’s 20-09.2019 Basic Authentication deprecation statement] :  

 

 -  that Basic Authentication is deprecated and will be disabled in Q3ish 2021 (?). Customers should replace it by Oauth2 authorization (including Openid Connect authentication), aka Modern Authorization

 

- that SMTP AUTH with Oauth2 using V2.0 authorisation and token endpoints and the Graph v1.0 api is available from May this year

 

- that SMTP AUTH is now disabled by default for new tenants, and can be enabled at the tenant level (using Powershell) or mailbox level (using Powershell or using the SMTP AUTH mailbox permission. Since this disabling is at the protocol level, OAuth2 for SMTP will be disabled by default.

SMTP itself is thus in effect deprecated but with no discontinue date.

 

 

Could MSFT then kindly clarify one simple point which may be obvious to everyone else:

 

Is the preferred way forward to use:

-  an Oauth2 access token as a bearer token acquired via MSAL

    to access

-  sendMail in Graph REST API (currently v1.0)?

 

 

And could MSFT clarify how this relates to the preferred authentication/authorisation and ‘send mail’   processes used in:

- desktop Outlook 2016 (onwards) – whose native preferred network protocol is MAPI over HTTP

- Android and iPhone phone/tablets – whose native preferred network protocol is EAS

I'll let @Sean_Stevenson answer the question of whether sendMail in Graph REST API is preferred to SMTP AUTH if he wants to (both are options), but I'll answer the follow on questions. Desktop Outlook uses MAPI over HTTP to send and receive (to retrieve and submit more accurately). And mobile devices - EAS allows the client to submit mail using that protocol. There's no separate sending protocol (such as SMTP AUTH) for either. 

 

SMTP AUTH is used by POP and IMAP clients, and apps/automation. 

Brass Contributor

Thanks Greg.

I guess my underlying (and unstated) thread was that the implementation of the mail protocols used in MSFT's cornerstone device-based products - MAPI over HTTP (for desktop Outlook) and EAS (for everything else) -  would appear to be different from the Graph API implementation that MSFT wishes developers to use. 

This not a criticism; I am just trying to understand MSFT's development direction and in particular whether the implementation of MAPI over HTTP and of EAS is intended at some date to use the Graph API instead.

MSFT has - correctly in my view - been progressively removing 'non-standard' implementations, e.g. the massive conversion of hotmail, live and outlook.com from a custom back-end to Exchange Online.

Microsoft

@Decomplexity 

Graph will always be the recommended option for developers looking to interface with our service for various actions including sending emails and it will have the most developer support and functionality. However given that SMTP AUTH is the widely adopted standard for sending emails, it'll be there for developers who wish to reuse code as much as possible for basic send functions.   

Copper Contributor

@Sean_Stevenson  @Sivaprakash_saripalli 
As mentioned here https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-i...

OAuth2 support for IMAP, POP, SMTP protocols as described below is supported for both Microsoft 365 (which includes Office on the web) and Outlook.com users.

does this mean Oauth2 support for imap, pop and smtp is supported for personal accounts having outlook.com domain? can we use the scopes and authorization code flow as mentioned in the doc for outlook.com personal accounts?

Steel Contributor

@Greg Taylor - EXCHANGE can you let us know if this is still the case: "At this time, there are no plans to enable IMAP and SMTP OAuth for non-interactive applications using client credentials flow. For that, we suggest to use our Graph API." ?

 

I think it would be awesome if we could do app-only (certificate credentials) to send messages via smtp.office365.com:587.  Much easier than MS Graph's s messages/send, which I'm overdue to figure out.

Copper Contributor

@Greg Taylor - EXCHANGE @Sean_Stevenson  @Sivaprakash_saripalli I was wondering if it is possible for an Administrator to enable SMTP only for OAUTH2 in Office365 but leave it disabled for AUTH (basic authentication) protocols? If so, how? I am happy to provide more information and clarify as needed. IMAP is enabled for OAUTH2 and works fine, but the administrator can not find the setting for enabling SMTP only for OAUTH2 and not for basic authentication, even on a per-user/application basis. For obvious reasons, we do not want SMTP to be enabled for both basic and OAUTH2. Also, if there is a better, more appropriate forum to post in, please let me know. Thanks!

Brass Contributor

I have long-standing problems authenticating SMTP using the V2 authorize and token endpoints and with the scopes set in Graph using the REST APIs and not MSAL. There appears from StackOverflow posts to be a widespread misunderstanding of the relationship between client scope URIs and AAD permissions URIs and so perhaps the Express team could resolve once and for all the question at the end of this post.  

 

BACKGROUND

MSFT said that SMTP AUTH would not be included in Graph - and hence in its permissions list - but only in Office365. But it then unexpectedly  appeared in Graph, and an enable/disable switch added to the tenant (accessible via Powershell) which could be overridden at user level (accessible via a pulldown in the user account). What was not widely publicised was that the default for new tenants was ‘disabled’, and this is at the protocol level so did not just affect Oauth2.  

 

Apparently less well known was that access tokens issued for the Graph API were V1 tokens even though they were requested from a V2 endpoint (V2 endpoints can issue V1 tokens and vice versa.) because access tokens are always of the type (version) appropriate for the API so you cannot mix API types in the same client scopes list. This caused us endless head-scratching when debugging during development. 

However this is not true for ID tokens which always conform to the endpoint version that issued them.

 

Finally, the access token scopes list must not span APIs anyway, so the client code needs to request tokens one by one. Since authorization codes cannot be reused, the common workaround appears to be to use the refresh token (acquired along with the first access token by specifying offline_access) to request a new access token for the second API, and so on.

 

As ledniov and others have commented, IMAP and SMTP AUTH scopes appear only to work when the scope URI in the client is either outlook.office.com or outlook.office365.com but the corresponding permissions in AD are in set in Graph and not in ‘legacy’ Exchange (the Exchange API simply does not have an SMTP.Send for example whereas Graph does). At this point my brain goes numb because scopes requested by a client (including the resource API’s URI - which for the V2 endpoints defaults to graph.microsoft.com if no URI is specified) for an access token MUST be a subset of the permissions for that API set by admin in AAD for that client or the entire granular permissions model falls apart.

 

@Sivaprakash_saripalli in a reply to question StackOverflow question 61597263 commented: “IMAP, SMTP scopes are targeted for Exchange resource and not Graph. Whereas User.Read, Mail.ReadWrite are meant for Graph resource”. Since many of us are confused at this apparent inconsistency, it would be appreciated if Sivaprakash or colleague could explain how if we specify an SMTP AUTH scope using https://outlook.office.com/SMTP.Send we should specify this permission to AAD when (e.g.) SMTP.Send is only selectable for Graph and not the Exchange API? Or is there a difference between a ‘scope’ URI used in the client and the corresponding permission URI specified for that API in AAD?

Brass Contributor

Sivaprakash-MSFT stated: “IMAP, SMTP scopes are targeted for Exchange resource and not Graph. Whereas User.Read, Mail.ReadWrite are meant for Graph resource” and developers on StackOverflow have noted that IMAP and SMTP AUTH scopes appear only to work when the scope URI in the client is either https://outlook.office.com or https://outlook.office365.com but with the corresponding resource permissions in AAD set in Graph and not  in ‘legacy’ Exchange because, unlike Graph, the Exchange API does not have (e.g.) an SMTP.Send permission.

 

Example:

Client:  scope ‘https://outlook.office.com/SMTP.Send

AAD: permission from Microsoft Graph (https://graph.microsoft.com) API’s list: SMTP.Send

 

It would be much appreciated by other posters and myself if @The_Exchange_Team  could explain how - if we specify an SMTP AUTH scope using https://outlook.office.com/SMTP.Send - we should specify this permission to AAD when (e.g.) SMTP.Send is only selectable for Graph and not the Exchange API?

Or is there a subtle difference between a ‘scope’ URI used in the client and the corresponding permission URI specified for that API in AAD? 

Surely scopes requested by a client (including the resource API’s  URI - which for the V2 endpoints defaults to graph.microsoft.com if no URI is specified) for an access token MUST be a subset of the permissions for that API set by admin in AAD for that client or the entire granular permissions model falls apart

Brass Contributor

@Sivaprakash_saripalli  stated: “IMAP, SMTP scopes are targeted for Exchange resource and not Graph. Whereas User.Read, Mail.ReadWrite are meant for Graph resource” and developers on StackOverflow have noted that IMAP and SMTP AUTH scopes appear only to work when the scope URI in the client is https://outlook.office.com but with the corresponding resource permissions in AAD set in Graph and not  in (e.g.) ‘legacy’ Exchange because, unlike Graph, the Exchange API (https://outlook.office365.com) does not have (e.g.) an SMTP.Send permission and there is no Outlook API shown in the API list at all.

 

Example:

Client:  scope ‘https://outlook.office.com/SMTP.Send

AAD: permission from Microsoft Graph (‘https://graph.microsoft.com’) API’s list: SMTP.Send

 

It would be much appreciated by other posters and myself if @Sivaprakash_saripalli or @The_Exchange_Team colleague could explain how - if we specify an SMTP AUTH scope using https://outlook.office.com/SMTP.Send - we should specify this permission to AAD when (e.g.) SMTP.Send is only selectable for Graph and not the Exchange API?

Or is there a difference between a ‘scope’ URI used in the client and the corresponding permission URI specified for that API in AAD? 

 

Scopes requested by a client (including the resource API’s  URI - which for the V2 endpoints defaults to graph.microsoft.com if no URI is specified) for an access token MUST be a subset of the permissions for that API set by admin in AAD for that client or the entire granular permissions model falls apart. I realise that Graph now includes much of the features of the Outlook REST API, but what confuses me and my colleagues is why the client scope URI and the AAD permissions URI are different.    

 

Copper Contributor

Hello exchange team, I've followed the steps from the provided instruction, using Javamail API, but it didn't work. As per Javamail API, we need to add an OAuth2Provider which'll encrypt the access token and user e-mail into base64("user=xxx@xxx.onmicrosoft.com^1auth=Bearer <Access token>^1^1). We have done the same, yet authentication fails. Can you please guide us with some working java code on how to authenticate using OAuth access token?

 

Regards,

Venkatesh

 

Brass Contributor
  1. Suggest you check that IMAP and SMTP AUTH are enabled for the email account (Admin / Active Users / [select user] / Mail tab / Manage email apps). There is also a tenant-wide setting accessible via Powershell. These settings are disabled by default for new tenants
  2. Check the ‘aud’ claim setting in the Access token (before base 64 encoding; use jwt.ms to display it). It should be https://outlook.office.com. If it is 00000003-0000-0000-c000-000000000000 (aka Graph) you are trying to access the wrong resource API
Copper Contributor

Is it possible to enable SMTP OAUTH2 (and not also enable the basic SMTP AUTH) for a tenant-wide or per-user setting? Where/how can this be set? Thanks in advance!

Co-Authors
Version history
Last update:
‎Jun 30 2022 11:43 AM
Updated by: