{"id":4323,"date":"2021-02-23T10:09:20","date_gmt":"2021-02-23T15:09:20","guid":{"rendered":"https:\/\/www.exchangedefender.com\/blog\/?p=4323"},"modified":"2021-02-23T10:09:22","modified_gmt":"2021-02-23T15:09:22","slug":"exchangedefender-oauth-support-for-google-and-microsoft-authenticators","status":"publish","type":"post","link":"https:\/\/www.exchangedefender.com\/blog\/2021\/02\/exchangedefender-oauth-support-for-google-and-microsoft-authenticators\/","title":{"rendered":"ExchangeDefender OAuth Support for Google and Microsoft Authenticators"},"content":{"rendered":"\n
<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

ExchangeDefender is proud to announce the successful rollout of the first phase of our OAUTH implementation<\/a> across three of our major products: ExchangeDefender Mail Security (Admin Portal), Encryption and WebShare. Originally, our rollout was planned to be a massive shotgun change across all services which would have required users to reset their passwords, but users had to be aware of their current password. In December, we started to log and analyze the entry points users took into the application and found that a majority of users relied on \u201cone-click\u201d login methods like quarantine reports to access their portal and would then jump to other services like Encryption via the \u201cquick links.\u201d Armed with the aggregated analysis, we realized our previous deployment strategy would unfortunately lead to many users being unable to access their services as many users were never aware of their password, thus putting an additional strain on our partners. However, we also know that the current security method was not sustainable for the future.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"<\/a><\/figure><\/div>\n\n\n\n
<\/div>\n\n\n\n

Enter: Deployment 2.0. <\/h3>\n\n\n\n
<\/div>\n\n\n\n

We knew our login system had to be smarter, safer, but also flexible. We knew we needed to rethink a lot of our auxiliary entry points (like quarantine reports) as well as our main entry points to work together in tandem, instead of hard cutovers or independent, one off operations. For example, we needed to continue to allow the legacy password hashing style to be accepted during login, but in-line upgraded to our new hashing algorithm. There were a lot of technical difficulties to overcome as each product maintained its own login page (which many users would save in their browser credential store) and in some instances, had additional security features that do not exist in other products (such as IP restrictions and 2FA in admin, but not encryption or Webshare). <\/p>\n\n\n\n

<\/div>\n\n\n\n

Even more complicated than individual service login logic, some services maintained a list of users who are external entities to the end user\u2019s organization (think Webshare or encryption recipients), and in most cases, these external recipients aren\u2019t in the ExchangeDefender eco system. Ultimately, we decided to allow ExchangeDefender users to continue using each service\u2019s independent login screens for a few weeks before disabling the legacy functionality and hinting to users to click the OAUTH login button \u201cLogin with ExchangeDefender\u201d (or even \u201cLogin with Google\u201d or \u201cLogin with Microsoft\u201d more details below).<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"<\/a><\/figure><\/div>\n\n\n\n
<\/div>\n\n\n\n

Originally, our plan involved redirecting all users to the new login server, which unfortunately would be the Achilles heal of those users who relied on their browser credential store. Ultimately, we landed on a hybrid approach, using the flexibility of using different OAUTH grant styles depending on the application. <\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"<\/a><\/figure><\/div>\n\n\n\n
<\/div>\n\n\n\n

The Deployment Timeline<\/h3>\n\n\n\n
<\/div>\n\n\n\n

Feb 19<\/strong>th<\/strong><\/sup>:<\/strong> Activate the new login system for Encryption and Webshare<\/p>\n\n\n\n

<\/div>\n\n\n\n

Feb 21<\/strong>st<\/strong><\/sup>: <\/strong> Activate the new login system for Admin<\/p>\n\n\n\n

<\/div>\n\n\n\n

Feb 26<\/strong>th<\/strong><\/sup>:<\/strong> Activate the new centralized navigation headers<\/p>\n\n\n\n

<\/div>\n\n\n\n

Feb 27<\/strong>th<\/strong><\/sup>:<\/strong> Activate \u201cLogin with ExchangeDefender\/Google\/Microsoft\u201d button to Admin, Encryption and Webshare. Add warning notification to users about the incoming login changes.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Mar 6<\/strong>th<\/strong><\/sup>: Disable legacy password grant from services, enforce \u201cLogin with ExchangeDefender\u201d when a user attempts to login with a username and password on each services page.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Throughout the remaining quarters of 2021, we will continue to integrate the rest of our services into the new login system, including support.ExchangeDefender.com, Compliance Archive, LiveArchive. Time permitted, we also plan on releasing a few tools to improve end user experience such as our Outlook\/OWA plugin, built from the ground up to manage quarantine and user whitelists.<\/p>\n\n\n\n

<\/div>\n\n\n\n

New Features to Expect<\/h3>\n\n\n\n
<\/div>\n\n\n\n

1 – Integration with Google and Microsoft OAUTH: Users are now able to utilize Google and\/or Microsoft as their login provider. Authenticated users will now see buttons to link their Google or Microsoft identity to their ExchangeDefender account. Once linked, users can utilize the \u201cLogin with Google\u201d or \u201cLogin with Microsoft\u201d buttons instead of inputting their ExchangeDefender credentials to login.<\/p>\n\n\n\n

<\/div>\n\n\n\n

2 – Improved 2FA integration: Users are now able to integrate 2FA applications like Google Authenticator or Authy. To setup 2FA users should login to admin.exchangedefender.com and navigate to the Settings for their account. Please keep in mind that the enforcement of 2FA logins (when enabled by the user) will come with the March 6th<\/sup> deployment. We strongly encourage users to set up 2FA before the full activation of our new login system.<\/p>\n\n\n\n

<\/div>\n\n\n\n

3 – Trusted Devices: Coupled with 2FA, users can elect to mark a device they\u2019re logging in with as a trusted device. Once a device is marked trusted, subsequent logins using the same device will not be prompted for 2FA again for 3 months.<\/p>\n\n\n\n

<\/div>\n\n\n\n

4 – Improved Remember Me: On our login server we improved the remember me functionality to allow users to remain authenticated for 7 days if selected during login.<\/p>\n\n\n\n

<\/div>\n\n\n\n

5 – Login to one, access to all: Users who now login to admin, encryption or webshare will inherently be authenticated to all other services using the new login method. This list will grow as we continue integrating services into the new login system.<\/p>\n\n\n\n

<\/div>\n\n\n\n

6 – Centralized Navigation: Users will see a consistent navigation system across all products utilizing the new login system. More importantly, navigation to other products is streamlined and consistent. <\/p>\n\n\n\n

<\/div>\n\n\n\n

7 – External Integrations: While redesigning the login system, we also elected to start centralizing API endpoints in anticipation of allowing partners and external providers to design their own tools and solutions, backed by ExchangeDefender. <\/p>\n","protected":false},"excerpt":{"rendered":"

[…]<\/p>\n","protected":false},"author":50,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-4323","post","type-post","status-publish","format-standard","hentry","category-exchangedefender"],"_links":{"self":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/4323","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/users\/50"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/comments?post=4323"}],"version-history":[{"count":34,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/4323\/revisions"}],"predecessor-version":[{"id":4362,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/4323\/revisions\/4362"}],"wp:attachment":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/media?parent=4323"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/categories?post=4323"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/tags?post=4323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}