Authentication and EWS in Exchange
Find information to help you choose the right authentication standard for your EWS application that targets Exchange.
Authentication is a key part of your Exchange Web Services (EWS) application. Exchange Online, Exchange Online as part of Office 365, and on-premises versions of Exchange starting with Exchange Server 2013 support standard web authentication protocols to help secure the communication between your application and the Exchange server.
If you're targeting Exchange Online, the authentication method that you choose must use HTTPS to encrypt the requests and responses that your application sends. Although you can use HTTP with Exchange on-premises servers, we recommend that you use HTTPS for any request that your application sends to an EWS endpoint to help secure communication between your application and an Exchange server.
Exchange provides the following authentication options for you to choose from:
OAuth 2.0 (Exchange Online only)
NTLM (Exchange on-premises only)
Basic (no longer recommended)
The authentication method that you choose depends on the security requirements of your organization, whether you are using Exchange Online or Exchange on-premises, and whether you have access to a third-party provider that can issue OAuth tokens. This article provides information that will help you select the authentication standard that's right for your application.
OAuth authentication
We recommend that all new applications use the OAuth standard to connect to Exchange Online services. The advantage in security over basic authentication is worth the additional work required to implement OAuth in your application. For the record, however, there are also some disadvantages that you should be aware of.
Table 1. Advantages and disadvantages of using OAuth
| Advantages | Disadvantages |
|---|---|
| OAuth is an industry-standard authentication protocol. Authentication is managed by a third-party provider. Your application does not have to collect and store the Exchange credentials. Fewer worries for you, because your application only receives an opaque token from the authentication provider; therefore, a security breach in your application can only expose the token, not the user's Exchange credentials. |
OAuth relies on a third-party authentication provider. This can impose additional costs on your organization or your customers. The OAuth standard is more difficult to implement than basic authentication. To implement OAuth, you need to integrate your application with both the authentication provider and the Exchange server. |
To help minimize the disadvantages, you can use the Microsoft Microsoft Entra Authentication Library (ADAL) to authenticate users to Active Directory Domain Services (AD DS) in the cloud or on-premises and then obtain access tokens for securing calls to an Exchange server. Exchange Online requires tokens issued by the Microsoft Entra service, which is supported by the ADAL; however, you can use any third-party library.
To learn more about using OAuth authentication in your EWS application, see the following resources:
Office 365 trial, to set up an Exchange server to use to test your client application.
Configure Microsoft Entra, to enable your application to use OAuth tokens for authentication.
Review the sample code in Authenticate an EWS application by using OAuth for example code that you can study.
NTLM authentication
NTLM authentication is only available for Exchange on-premises servers. For applications that run inside the corporate firewall, integration between NTLM authentication and the .NET Framework provides a built-in means to authenticate your application.
Table 2. Advantages and disadvantages of using NTLM authentication
| Advantages | Disadvantages |
|---|---|
| Works "out of the box" with your Exchange server. You can configure access to Exchange services by using an Exchange Management Shell cmdlet. Uses the .NET Framework CredentialCache object to automatically get the user's credentials. Code samples are available that use the logged on user's credentials for authentication to an on-premises Exchange server. |
Users must be logged on to a domain to use NTLM authentication. It can be difficult to access email accounts that are not associated with the user's domain account. Service applications must have a domain account to take advantage of NTLM authentication. |
Basic authentication
Basic authentication provides a, well, basic level of security for your client application. We do recommend that all new applications use either NTLM or the OAuth protocol for authentication; however, basic authentication can be the correct choice for your application in some circumstances.
Table 3. Advantages and disadvantages of using basic authentication
| Advantages | Disadvantages |
|---|---|
| Works "out of the box" with your Exchange server. You can configure access to Exchange services by using an Exchange Management Shell cmdlet. Windows applications can use the logged on user's default credentials. Many code samples are available that show you how to call EWS using basic authentication. |
Requires your application to collect and store the user's credentials. You have to turn off NTLM authentication if you want to force all users to use basic authentication. If a security breach occurs in your application, it can expose the user's email address and password to the attacker. |
You need to decide if basic authentication meets the security requirements of your organization and customers. Basic authentication can be the right choice if you want to avoid extensive setup tasks, for example for simple test or demonstration applications.
Note
Basic authentication is no longer supported for EWS to connect to Exchange Online. Use OAuth authentication in all your new or existing EWS applications to connect to Exchange Online. OAuth authentication for EWS is only available in Exchange Online as part of Microsoft 365. EWS applications that use OAuth must be registered with Microsoft Entra first.