Last year, Microsoft announced that they intended to disable the option of using Basic Authentication access to Exchange Online for Microsoft 365 customers in October 2020. A few months later, Google also announced that they would be switching off less secure app access (which is Google’s counterpart for Basic Authentication) to Google G Suite accounts in June 2020. However, due to the current COVID-19 pandemic, these deadlines have been postponed. While Google says the switch-off is suspended until further notice, Microsoft has now announced the following:
- Basic Authentication will be disabled by default for new Microsoft 365 tenants starting October 2020
- Basic Authentication will also be disabled for existing Microsoft 365 tenants which have no recorded usage starting October 2020
- Disabling Basic Authentication for Microsoft 365 tenants who are actively using it is now planned for the second half of 2021
- Customers may already disable Basic Authentication for their Microsoft 365 tenants themselves
Even if you are a customer of Microsoft 365 or Google G Suite and have yet to be affected by the disabling of Basic Authentication, you should get to grips with the topic of Modern Authentication right now! Modern Authentication is not only much more secure than Basic Authentication: it may also offer a much better user experience. But let’s start with the basics.
What Is Basic Authentication Actually?
To understand how Basic Authentication actually works, here is an analogy. Imagine the following scenario: You fly abroad, leave the plane and are heading for the border control. And now let’s pretend that the process works a bit different than you are used to. Instead of showing your passport, you tell the security officer: “Hi, my name is John Doe, my password is XYZ and I’m originally from Germany”. With this information, the security officer gives the national authorities in Germany a call and explains the following: “There’s a guy at my desk who wants to enter our country. He says he’s from Germany, his name is John Doe and his password is XYZ. Is that correct?”. The authorities check the information and confirm it. So, the security officer is happy to tell you that your information is correct and you’re allowed to enter the country. Such a procedure at the border control wouldn’t feel quite right, would it? So, what’s wrong with this approach? First, there are no additional checks like a passport with additional information like a photo, etc. How would the security officer know you are the person you are claiming to be? Anyone who knows your name and your password could pretend to be you. Second, you have to disclose information that is supposed to be confidential to another person and you have to trust the security officer. This is basically how Basic Authentication in the digital world works.
The History of Basic Authentication
Originally, the term “Basic Authentication” described an authentication scheme which is defined in RFC 7617 and which was originally created for HTTP authentication. If you go to a website and a browser popup asks you to enter your user name and password, this is what is originally described by “Basic Authentication”. This kind of authentication is also used as an authentication scheme in Microsoft Exchange Servers. It is also known as simple authentication, plain text authentication, or less secure apps (Google). So, to wrap up the definition: Basic Authentication is any authentication based on plain user names and passwords.
What Are the Issues With Basic Authentication?
In the digital world, owning credentials basically means owning the resource you want to access with these credentials. The service on which the resource is stored cannot distinguish between you and any other person who has your credentials. With regard to Microsoft 365 or Google G Suite, this means that if you want to give someone access to your mailbox, they could use the same credentials to access Microsoft SharePoint, Teams and other services on your Microsoft or Google tenant. With technology based on Basic Authentication, it is barely possible to limit access to other resources which can be accessed with the same credentials. This means that with Basic Authentication, the gateways to your data are wide open and they should be protected. So, if all this sounds so risky and insecure, why have we been using this kind of authentication in the digital world for so long?
What Is Modern Authentication?
Modern Authentication is an umbrella term originally defined by Microsoft, but many other companies also use it to describe a set of the following:
- Authentication methods (authentication = how something/somebody logs in to a system)
- Authorization methods (authorization = mechanisms that make sure you do not have full access to something by default)
- Conditional access policies (policies which define the conditions under which certain additional steps have to be taken in order to log into a system)
Authorization and authentication methods are standardized in the digital world. The industry standard for authorization is OAuth2. For authentication there is no industry standard, but the standard which is most widely used is OpenID Connect. Although they serve different purposes, these standards are very much related from a technology standpoint. The OpenID Connect protocol suite extends the OAuth protocol and they are based on the same technologies. OAuth was never designed to authenticate users or persons, but only services. That is why OpenID Connect was created.
How would Modern Authentication look like in our airport analogy? With Modern Authentication, the procedure seems quite familiar: You fly abroad, leave the plane and go to the security officer at the border control. The officer asks to see your passport on which he can find all the important information needed to identify who you are and where you are from. This information is protected by anti-forgery mechanisms. In the digital word, the passport is what we call an ID token. This token contains important information: who you are, who created the token, how long it is valid, etc.
Where Does Multi-Factor Authentication (MFA) Fit Into the Mold?
Two-Factor Authentication (2FA) and Multi-Factor Authentication (MFA) are a part of the authentication process. The process is as follows: You as a user connect to your identity provider who needs to validate that it is really you trying to connect. Depending on the conditional access policies which are defined by the administrator, your identity provider might ask you for further information. If he believes that just entering your credentials is not enough to authenticate you, for example when you are connecting from an unknown network, he may ask you for additional information, for instance a code which is sent to your mobile phone. Microsoft has implemented this in a very dynamic way. Their systems continuously learn and decide what is a secure system and what is not. There is also the possibility to define a device as secure, for example your business laptop. If a device is defined as secure, you will be asked for your credentials just once and then a cookie is stored in your browser, so, the next time you log in, you are immediately logged in without asking for your credentials or further details again. These are additional policies an administrator can define, and this is especially relevant at times like these where many people are working from home (for example when using an insecure network instead of a corporate VPN at home).
What’s the Advantage of Modern Authentication
One of the biggest benefits for administrators is that all these policies are just configured at one central location which is at the identity provider. This means that the more applications are connected to the identity provider, for example the Microsoft Azure Active Directory and the identity services provided by Microsoft, the more convenient it is to configure conditional access policies for all these applications. This way, the administrator does not have to configure individual login policies and security settings for each application. There is just one location where the administrator can define the login policies for all the applications that are integrated with the identity provider. In the long run, the more applications that support this kind of authentication, the more user-friendly and easier it is for the administrator. And of course, Modern Authentication is much more secure than Basic Authentication.
How Does Authentication Work in MailStore Server and the MailStore SPE?
MailStore Server and the MailStore Service Provider Edition (SPE) need authentication when users are synchronized from a directory service, in order to access mailboxes, to archive or export messages, and when users want to log in to their MailStore archives to access emails. In the following, we’ll explain how authentication with Microsoft 365 and Google G Suite worked with Basic Authentication and how it works with Modern Authentication when using MailStore Server or the MailStore SPE. From here on, to improve readability, we’ll only refer to MailStore Server even though all of the below actually applies to the MailStore SPE as well.
MailStore Server & Basic Authentication
How did authentication with Microsoft 365 and Google G Suite work in the past? Originally, a user would open the client application (which is the MailStore Client, MailStore Outlook Add-in or MailStore Web Access), enter his credentials, and send them to MailStore Server. Then, MailStore Server would notice that this particular user was synchronized from a remote directory service. In this case, MailStore Server would connect either to the directory service itself (if that service provided an authentication interface) or, in the case of Microsoft 365, try to log in to the Exchange Online mailbox of the user with the given credentials. If the login to the mailbox was successful, this was communicated to MailStore Server. Then, MailStore Server would tell the client application that the credentials were correct and the user is logged in and can search the archive.
This is how the Microsoft 365 profile worked with Basic Authentication (and still does because the option is still available).
MailStore Server & Modern Authentication
How does Modern Authentication with Microsoft 365 and Google G Suite work with MailStore Server now? In a first step, the user enters his user name only. Then, MailStore Server checks if the authentication attribute of that user is either set to MailStore integrated, or to directory services and what type of directory service is currently configured. Depending on the result, the user is either asked for a password, or, if the configured directory service supports Modern Authentication, is redirected to a third-party identity provider. In the case of Modern Authentication with Microsoft 365, MailStore Server will return a sign-in URI of the identity provider. When using the MailStore Client or the MailStore Outlook Add-in, a web browser is opened automatically to open the sign-in-URL of your identity provider. When using MailStore Web Access, users are redirected automatically to the sign-in-URL of their identity provider. What happens next? That depends on the conditional access policies defined by the admin. If the user logs in from a secure network for which the administrator has not defined additional policies, then entering the credentials is typically sufficient. If the administrator has defined additional policies, the user may be asked to enter additional information (e.g. with MFA). If authentication with the identity provider was successful, the identity provider knows to which application the user originally wanted to log in. Thus, the identity provider redirects the user back to MailStore Server and has him submit an ID token which is sent to MailStore Server. The ID token is validated by MailStore Server and additional user information is requested from the identity provider (for example the alias address). This helps MailStore Server to map the MailStore user to the user that is trying to log in. Then, the session is marked as authenticated and the user can access the archive.
Although (some of) the deadlines for disabling Basic Authentication and less secure app access have been postponed, it is worth looking into switching to Modern Authentication as early as possible. Modern Authentication is not only far more secure than Basic Authentication but also more user-friendly and makes the life of the administrator easier. MailStore Server and the SPE support Modern Authentication through OAuth2 and OpenID Connect since version 13, which significantly enhances MailStore’s integration in the cloud-based environments of Microsoft 365 and Google G Suite.
If you are using Microsoft 365 and would like to start using MailStore Server, we recommend our Tech Tip Archiving Microsoft 365 Emails for New MailStore Server Customers. The two videos in this Tech Tipp show you how to connect MailStore Server with your Microsoft 365 tenant using Modern Authentication, how to synchronize users, and how to customize archiving profiles.
Are you using Microsoft 365 but aren’t yet aware of the benefits of using a third-party email archiving solution like MailStore Server? Then take a look at the free whitepaper created by the market research institute Osterman Research. You can learn more about this in our blog article Archiving Emails in Microsoft 365.
A well-arranged summary on the topic of modern authentication can be downloaded here:
Further useful information can be found here:
- Synchronization of user accounts with Microsoft 365 (Modern Authentication)
- Archiving emails from Microsoft 365 (Modern Authentication)
- Archiving emails from G Suite
About the author:
This article was written by Daniel Weuthen. Daniel is Director of Engineering at MailStore Software GmbH.