Bugzilla

A few things to consider:
* In Thunderbird, use OAuth2 only when it's necessary. It gives a poor customer experience, because OAuth expires and the user has to re-login, at unknown intervals, it's completely up to the server, whether it's 3 hours or 3 months. We cannot save the password. One of the primary reasons why people want to use Thunderbird instead of Outlook Web Access is because they don't want to re-login, but be automatically logged in. So, long story short: Do not enable OAuth2 for all users, but only those where it's absolutely necessary. In Owl, we check at setup which authentication is available for a given account, and prefer automatic background logins without webpage wherever possible.

* Even Office365 support custom authentication, with login pages hosted at the premises of the enterprise. That might be Microsoft's auth server, or a fully custom page. So, even if it works in the cases you tested, it doesn't mean it will work for other users.

* There are tons and tons of variations. In fact, supporting the login pages so that it works for all users was a royal pain and took several weeks of development. It worked for us, but not for some of our customers. You can imagine how difficult that was.

This is *not* just a question of putting some config data in somewhere. You might break more users than you fix.

A few things to consider:
* In Thunderbird, use OAuth2 only when it's necessary. It gives a poor customer experience, because OAuth expires and the user has to re-login, at unknown intervals, it's completely up to the server, whether it's 3 hours or 3 months. We cannot save the password. One of the primary reasons why people want to use Thunderbird instead of Outlook Web Access is because they don't want to re-login, but be automatically logged in. So, long story short: Do not enable OAuth2 for all users, but only those where it's absolutely necessary. In Owl, we check at setup which authentication is available for a given account, and prefer automatic background logins without webpage wherever possible.

* Office365 supports custom authentication, with login pages hosted at the premises of the enterprise. That might be Microsoft's auth server, or a fully custom page. There are zero standards. So, even if it works in the cases you tested, it doesn't mean it will work for other users.

* There are tons and tons of variations. In fact, supporting the login pages so that it works for all users was a royal pain and took several weeks of development. It worked for us, but not for some of our customers. You can imagine how difficult that was.

This is *not* just a question of putting some config data in somewhere. You might break more users than you fix.

A few things to consider:
* In Thunderbird, use OAuth2 only when it's necessary. It gives a poor customer experience, because OAuth expires and the user has to re-login, at unknown intervals, it's completely up to the server, whether it's 3 hours or 3 months. We cannot save the password. One of the primary reasons why people want to use Thunderbird instead of Outlook Web Access is because they don't want to re-login, but be automatically logged in. So, long story short: Do not enable OAuth2 for all users, but only those where it's absolutely necessary. In Owl, we check at setup which authentication is available for a given account, and prefer automatic background logins without webpage wherever possible.

* Office365 supports custom authentication, with login pages hosted at the premises of the enterprise. That might be Microsoft's auth server, or a fully custom page. So, even if it works in the cases you tested, it doesn't mean it will work for other users.

* There are tons and tons of variations. In fact, supporting the login pages so that it works for all users was a royal pain and took several weeks of development. It worked for us, but not for some of our customers. You can imagine how difficult that was.

This is *not* just a question of putting some config data in somewhere. You might break more users than you fix.