- Products
- Solutions Use casesBy industry
- Developers
- Resources Connect
- Pricing
On October 1st, 2022, Microsoft will deprecate basic authentication for Microsoft Exchange Accounts as a means of authentication. This will affect Microsoft and Office 365 accounts as well as Exchange Server accounts in a Hybrid Deployment. Accounts and organizations that do not migrate away from basic authentication before this date will experience authentication outages with all services including Nylas. This guide covers basic authentication, various information on the process of depreciation, and how to make this transition as smoothly as possible.
Basic authentication is a process where the application sends both username and password with each request to a server or Application Process Interface (API) endpoint. This information is often cached or stored on the device used to make the request. Due to its ease of use, it is often enabled by default for many older applications (and sometimes more recent ones). Microsoft states that this change is occurring to increase security for Microsoft Azure applications as basic authentication can be more easily infiltrated by a bad actor. The deprecation of basic authentication will also disable the use of app password for applications that do not have two step verification enabled.
Here’s an example of what a generic basic authentication request would look like using cURL:
curl -H 'Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=' https://example.com
The way this would breakdown, is like this:
Authorization: ‘Basic’ + b64encoded(username:password)
When the request arrives, the information is decoded, and checked to make sure it matches the credentials on file.
Nylas provides basic authentication as an option for use with every Nylas endpoint. It is required if you are using Account Management or Webhooks. See the details in the Basic Authentication documentation from the Nylas API reference.
If you want to use Microsoft methods to see if your application uses basic authentication, there are various ways to check.
One of the easiest ways is during login to the application. If it is a web based log in, such as the below image, the application is using a modern authentication method and that would be a good sign.
If the login window looks like the below image, it indicatesthat would indicate the use of basic authentication.
Additionally, you can check the Azure message center as Microsoft started to send messages back in late 2021 to explain and summarize an application’s usage of basic authentication. This report will notify the admins of an application about users who authenticated with theirinto their application within the last month using basic authentication. This would not cover users who had not logged in during this timeframe.
Another method for ensuring the impact of this migration will be minimal would be to check the Azure Active Directory Sign-in report. The report would allow you to see unexpected usage of basic auth that other methods might not catch. This would be signified as “legacy” auth usage. You can check the following official Microsoft documentation for more methods of verifying the usage of basic authentication.
September 2021 – Basic authentication update
July 2022 – Basic Auth Deprecation for Exchange Online
Important Information for My Nylas Application
Nylas already recommends that users who have not yet created an Azure App do so for authentication Exchange Online (Microsoft 365) accounts to avoid service disruptions on or before the depreciation date. At the time of writing, Microsoft has already expressed that they are selectively choosing users to disable basic authentication for a short period. This is done randomly by Microsoft as the deprecation date approaches. If an admin does not reenable this feature using Microsoft’s self-service tools, this could cause a disruption with Nylas.
Furthermore, Nylas will stop support for basic authentication on all applications using Exchange online and hybrid deployment accounts on September 30, 2022. What this means is that Nylas will invalidate all credentials for these accounts. Any users who are authenticated via basic authentication will need to re-authenticate using OAuth to start syncing again.
The following section will help guide you to minimize the effects of this change for your users and ensure the smoothest transition possible.
How to Prepare my Nylas Application
As mentioned earlier we recommend creating an Azure App if one has not already been created for your application. The Nylas documentation has a robust guide on setting up an Azure App with Nylas which can be found on the Create an Azure App for Microsoft Integration page. You will want to ensure that your application has the needed Microsoft Graph permissions. You can learn more about how Nylas works with Microsoft Graph on the Microsoft Graph for Events page. Depending on the types of information you are leveraging, you will need:
Ensuring that your application has the required scopes for Nylas is crucial for your application. Not enabling the correct scopes can lead to authentication problems for your users. Once the Azure App is set up, all new users will automatically be authenticated using an OAuth process.
Set up OAuth Authentication
You can follow our guides for setting up either hosted or native authentication with Nylas. You can learn more about which version of authentication is right for you here. If at any point you find difficulty in this, reach out to your customer support manager. New users working with Nylas can use the chatbot from the Nylas home page to be connected with a member of our team to help.
Programmatically Using Nylas to Identify and Re-Auth Users
To identify the affected users, you GET /a/{client_id}/accounts
endpoint and filter by provider=eas
and provider=ews
with the authentication_method=password
to return all accounts authenticated with basic auth. These are the accounts that will need to re-auth using OAuth. You can decide how you want to notify these users or if you want to re-auth them.
An example Python script for how this can be done is as follows:
import requests import json import base64 nylas_client_id="" nylas_client_secret="" auth_header = base64.b64encode(nylas_client_secret.encode("utf-8") + b":") headers = { b'Content-Type': b'application/json', b'Authorization': b'Basic ' + auth_header } pagination_offset = 0 pagination_limit = 50 exchange_providers = ["eas", "ews"] exchange_password_accounts = [] while True: url = "https://api.nylas.com/a/{}/accounts?offset={}&limit={}".format(nylas_client_id, pagination_offset, pagination_limit) response = requests.request("GET", url, headers=headers) if response.status_code != 200: break data = response.json() if len(data) < pagination_limit: break for account in data: if account.get("provider") in exchange_providers and account.get("authentication_type") == "password": exchange_password_accounts.append(account) pagination_offset += len(data) print(exchange_password_accounts)
Invalidating Tokens for Affected Accounts:
Using POST api.nylas.com/a/{client_id}/accounts/{id}/revoke-all
with the query parameter ?trigger_webhook=true
which will trigger the account.invalid
webhook. This method can be used to trigger a re-authentication flow for the required users.
It is recommended that this approach be done in smaller batches to ensure that this process works for you and your application. There is still time to roll this out and minimize possible service disruptions.
Final Remarks:
For any questions, please either reach out to your dedicated customer success manager or the sales team. We are all happy to help with the process in any way we can. Nylas is always aiming to make changes to the process as seamless as possible.