Sage CRM 2020 R2: Understanding OAuth 2.0

One of the big things we're facing for this release is the introduction of OAuth EWS authentication.  This, along with the TLS work has taken a lot of our development resource in this current six month cycle.  

Microsoft calls its implementation of OAuth 2 "Modern Authentication" so for the purposes of this article the two terms are interchangeable.

Microsoft's Modern Authentication uses the Active Directory Authentication Library (ADAL)-based sign-in that is used for Office 365 apps. Most importantly it enables sign-in features such as Multi-Factor Authentication (MFA).

In September of 2019 Microsoft announced that they would retire Basic Authentication services access to Exchange Online from October 13th 2020. 

These services included

  • Exchange Web Services (EWS)
  • Exchange ActiveSync (EAS)
  • Internet Message Access Protocol (IMAP)
  • Post Office Protocol (POP)
  • Remote PowerShell (RPS)

Importantly the change to EWS and POP has an implication for Sage CRM's integration with Exchange and the Advanced Email Manager.

Note: COVID 19 has disrupted everything and Microsoft announced on 3rd April 2020 that the retirement date for Basic Authentication for Exchange Online would be deferred until the second half of 2021.

This April announcement has helped us in that we now no longer have to worry about the patching of older versions of Sage CRM to take this into account – basically we will be supporting Modern Authentication from Sage CRM 2020 R2 onwards.  By the time that Modern Authentication is enforced we should have 3 releases of Sage CRM supporting OAuth 2.0. 

Note: This does not impact on-premise implementations of Microsoft Exchange which can still use Basic Authentication.
Note: This change does not impact SMTP AUTH. 

The integration between Sage CRM and Exchange uses the Exchange Web Services.
These are a SOAP based web service and the interact is an HTTP transaction. Basic Authentication is a method for the client (Sage CRM) making the request to provide a user and password to the EWS. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>. <Credentials> represents the Base64 encoding of ID and password.

Basic Authentication provides no confidentiality protection for the transmitted credentials. They are merely encoded with Base64 in transit, but not encrypted or hashed in any way. Therefore, basic authentication is typically used in conjunction with HTTPS to provide confidentiality. And HTTPS runs over TLS and so you can see that security changes were a big 'thing' for this development cycle.

OAuth (the latest version of which is OAuth 2.0) represents a step forward in the use of credentials for authentication of API service users. It is a major advance on the basic HTTP access authentication method.

OAuth works by providing to clients, such as Sage CRM, a "secure delegated access" to a server resource, like Exchange, on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. OAuth essentially allows access tokens to be issued to a 3rd-party application like Sage CRM by an authorization server, with the approval of the resource owner. The Sage CRM then uses the access token to access the protected resources hosted by the resource server.

The BIGGEST difference I think between Basic Authentication and OAuth 2 is that when an application logs on with Basic Authentication they are using your credentials directly. Once that application logs on it has the same rights as the original owner so is to all intents and purposes 'You'. But OAuth 2 uses this idea of 'secure delegated access'. That once the token is obtained that token is the symbol that determines what the application can do. It not longer has owner access. But it can only do what you have allowed the application to do.