- 24 March, 2021 - 5 ’ read

OAuth 2.0 support: Microsoft 365 native integration.

Imagicle UCX Suite, MS 365, OAuth Support, Spring Release 2021

How many times have you had to enter your credentials again and again to access a service? Well, all this becomes a thing of the past with OAuth 2.0. Spring 2021 Release will be here soon, and this is the first of its flowers: get ready to discover OAuth 2.0, its benefit in terms of security and simplicity, and its use cases within the Imagicle UCX Suite.

What is OAuth 2.0?

OAuth 2.0 (Open Authorization) is an open standard used for token-based authentication and authorization.
It allows the sharing and use of a user’s information by a third-party service, without requiring or exposing the user’s credentials.

OAuth 2.0 acts as an intermediary between the user and the service: it provides the service with an access token that authorizes the sharing of specific user information. The typical example of OAuth 2.0, which you’ve undoubtedly encountered before, is accessing a service (e.g. Spotify) using the login credentials of another service (e.g. Google, Facebook).

The user credentials are therefore replaced by a token, issued by the service to which we ask for them and which maintains the requested resources. In this way, accessing those resources will no longer require the exchange of sensitive information by the service/user requesting them, but the token itself will guarantee access. As an additional layer of security, each token has a validity period. Once expired, the token’s validity is revoked. In any case, the service that provided the token can revoke its validity.

How OAuth 2.0 works.

OAuth 2.0 defines four roles:

resource owner, the user who authorizes an application to access their account;
resource server, which hosts the protected user accounts;
authorization server, which verifies the identity of the user before issuing access tokens to the application;
client, the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the authorization server.

Let’s dive into the diagram above with a better explanation of the flow:

The Client requests authorization to access service resources from the user
If the Resource Owner authorizes the request, the Client receives an authorization grant
The Client requests an access token from the authorization server by presenting authentication of its own identity and the authorization grant
If the application identity is authenticated and the authorization grant is valid, the authorization server issues an access token to the application. Authorization is complete.
The application requests the resource from the resource server and presents the access token for authentication
If the access token is valid, the resource server serves the resource to the application

If the explanation of what OAuth 2.0 is and how it works has left you with a lot of questions, it’s quite normal: OAuth 2.0 is a framework that specifies the guidelines and does not provide the final implementation. The flow presented here is abstract and generic, it can change depending on the grant types on the requested resources and can differ between different authorization servers (for example Microsoft/Google use their own implementations. In any case, they respect the standard RFC).

What makes OAuth 2.0 more secure.

Usually, the authentication method proposed by any service is Basic Auth, which has the following disadvantages:

the user needs to share their credentials with the service;
the user does not have the possibility to stop the service from using their resources;
there is no standardization for an authentication flow, so every service implements its own flow without respecting an RFC standard.

In addition, Microsoft is going to drop the support to Basic Auth on Microsoft 365. As stated from the Tech Community February update, The Basic Auth dismission by Microsoft started is continuing and will be completed in a matter of time. 2021.Spring.1 release arrives just in time to maintain a perfect feature continuity in our products.

OAuth 2.0, with respect to Basic Auth, brings a lot of advantages:

relies on SSL to ensure data;
it uses tokenization to give limited access to the user’s data and prevent accessing when authorization tokens expire;
it allows sharing data without having to release personal information;
it is easier to implement and provides stronger authentication;
it supplies the authorization workflow for web, desktop applications, and mobile devices.

OAuth 2.0 in the Imagicle UCX Suite.

Now that we have a general understanding of what OAuth 2.0 is and what roles are participating, let’s move on to explore the integration within Imagicle services.

Starting from 2021.Spring.1, we have made integration with Office 365 services more secure with OAuth 2.0. In this particular context, OAuth 2.0 roles are played by:

Resource Owner: the UCX Suite or Attendant Console user
Resource/Authorization server: Office 365 services
Client: Imagicle services, e.g. Digital Fax

Imagicle leverages OAuth 2.0 to connect to Office 365 services. For this reason, if calendar integration or Email To fax were already configured using Office 365 services, upgrading to the latest UCX Suite version this integration will continue to work, guaranteeing greater security and solving the future problem related to the Basic Auth dismission.

Features that currently support it are:

Digital Fax’s Email to Fax
Calendar integration in Attendant Console

To summarize, when Basic Auth is dismissed from MS you won’t be able to use Email to Fax or the Calendar Integration in our Attendant Console, unless you update your Imagicle UCX Suite to 2021.Spring.1 release.

Let’s look specifically at how individual services leverage this integration.

Email to Fax.

Email to Fax allows you to send faxes (with attachments) directly from your email client.

To take advantage of OAuth 2.0, you must follow the guidelines to configure your Email to Fax service.

Email to Fax uses OAuth 2.0 to connect to the configured mail folder and download emails.

The grant we chose and implemented is Client Credentials. The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user. This is typically used by daemons/services (as Digital Fax) to access resources about themselves rather than to access a user’s resources.

Calendar integration.

A previous post introduced the calendar integration within the Attendant Console. This integration now supports OAuth 2.0.

As of 2021.Winter.2 you can choose a new authentication model called “Modern authentication”. Although the name is different, behind the scenes the implementation mirrors the guidelines of the OAuth 2.0 specification. The flow and grant type implemented is Authorization Code. This grant type is used when the client wants to request access to protected resources on behalf of another user. In this case, the user will be logging in on Office 365 services. Unlike the Client Credentials grant, used for Email To Fax, user interaction is therefore required.

You can configure the new “Modern authentication” via the Calendar options panel.

Conclusions.

OAuth 2.0 has become de-facto the standard for authentication and authorization. Its advantages over Basic Authentication are crucial, especially now that integrations between different third-party services have become the rule and no longer the exception. Implementing OAuth 2.0 not only allows us to achieve a higher level of security but also greater compatibility and feature continuity (remembering that Basic Authentication for Office 365 will be discontinued soon).

Stay tuned on our blog and website to remain up to date and not miss a single thing. It’s going to be Imagicle!