Proposal: Enable OAUTH client extension by default now that microsoft has discontinued username/password authentication

What the subject says. For new installs only, but with maybe an upgrade message if it detects you have a microsoft email account enabled.

added type:proposal label

changed the description

I would prefer that this be enabled just by those who need it. I'd rather not have enabled by default on existing installs.

I had updated the description to say new installs only. I can see an argument for not even doing that but then I have a reverse question: Are there still any email services that do NOT support OAUTH? (besides home-grown/self-hosted)

Most of our sites use IMAP with traditional providers that don't use OAUTH. I have very few sites that use Google and none that use Office365 so we have OAuth enabled on only 2 sites. So I see that as such an edge case that enabling on new sites doesn't make sense.

Most of our sites use IMAP with traditional providers that don't use OAUTH.

I guess I prefer to turn on a feature as opposed to having to disable it.

Oh - I also don't use IMAP for bounce processing - we use sendgrid or AWS so the API handles that so this limits us to possibly needed OAUTH for incoming emails only.

Ok. Perhaps this could then just be limited to an upgrade message on sites that have an existing non-OAUTH microsoft account. Or not even that.

I am not dead set against this - if the majority need OAUTH these days, I am happy to have the change. I assumed my use case is typical which it may not be.

FWIW I have a roughly equal mix of folks using a webhook endpoint for bounces, using Google/Microsoft-hosted bounce emails, and non-Google/Microsoft bounce emails.

@DaveD I like your last suggestion of making this an upgrade message on sites that have an existing non-OAUTH MS account. For outgoing mail relayed through MS, is there a limited number of URLs? E.g. with Google it'll always be smtp-relay.gmail.com or smtp.gmail.com. Those folks should also get an upgrade warning IMO.

Also hopefully once people attempt this upgrade we'll finally iron out the quirks in MS-based OAuth. I unfortunately don't have access to the Azure control panel on the client that needs to use this.

For outbound, I don't believe civi yet supports OAUTH unless I missed some PRs, which is possible. That may be a whole separate issue which I know there's a ticket open for already but may now be more urgent.

And yes I've seen that it's not always smooth to set up for MS because of how the tenant id is not configurable.

added comp:OAuth label

added triaged label

The tenant ID will now be configurable as of 5.59+ [=

I think Microsoft has now disabled basic auth across the board (unless someone's specifically requested an extension) - https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online

So have we missed the boat a bit here?

I feel like most sysadmins who could be affected by this will now be aware of it.

I was made aware of it when our bounce processing stopped working, and it took us a couple of weeks to notice (facepalm).

It feels like something that might warrant a blog post rather than a global update message?

Thanks for your work on this. I can do a little blog post.

Blog: https://civicrm.org/blog/daved/how-pronounce-oauth-and-what-you-need-know-about-it

Cool, so I suppose this can be closed unless anyone thinks more follow-up is needed?

closed