Do you consent to learning about modern authorization in Microsoft 365?

If you are reading this article, then you have more than likely been presented with an authorization consent prompt in an application you were using. Usually, this takes place the first time we use an application or when we try to use a new feature within an application for the first time.

My experience has been that people unfamiliar with this style of consent prompt find it quite confronting or even alarming, and there is often a reluctance or fear to give consent. In this article, we are going to explain this modern approach to authorization to help you understand its purpose and how it makes things safer for you and your data.

Firstly, let's clear up a common area of confusion, authentication and authorization are different things, and it is important for this discussion that we understand the role each plays.

• Authentication: Is proving a user's identity. It is when someone (or something) authenticates to prove that they are the user they claim to be.
• Authorization: This is the process of determining what resources a user has access to.

Often authentication and authorization are presented to the user together, so they feel like they are the same thing. This often takes the form of being challenged to sign in before getting access to something. Let's use the analogy of a building access pass to illustrate the difference.

When you first enter the building a security officer compares the photo id on the pass to your actual appearance to verify that you are the person the access pass is for. This is proving your identity, that you are who you say you are. This is authentication. Once you get into the foyer of the building though you can't just go anywhere you want, maybe your pass only lets you go to certain levels in the elevator and will only open certain doors. The elevator and doors are all resources, and your pass gives you access to some resources but not others. This is authorization.

With those concepts defined we can now look at how applications access your data stored in Microsoft 365. The approach used when you see the consent prompts is defined by an open standard for access delegation called Open Authorization (OAuth). OAuth allows you to approve (give consent) to a third-party application interacting with your Microsoft 365 data on your behalf without giving away your password. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth allows access tokens to be issued to third-party applications by an authorization server (Microsoft Identify Platform), with the approval of the resource owner (that's you as the owner of your data in Microsoft 365). The third-party application then uses the access token to access the protected resources hosted by the resource server (that's your Microsoft 365 data hosted in the cloud).

Let's look at this interaction from the third-party application point of view in the case it wanted to read the user's mail. Rather than prompt the user for their Microsoft 365 username and password (and store these credentials within the third-party application), instead, the application can delegate the entire authentication process and authorization process to the Microsoft Identity Platform effectively asking can you please ensure this user is who they say they are, and once you've done that can you make sure they are ok with me reading their mail. In response, the Microsoft Identity Platform will ensure the user has authenticated (including multi-factor authentication if configured) and will also ensure the user has granted consent (authorized) for the application to read their mail. Once both the validation checks pass, the Microsoft Identify Platform will issue the application an access token that can be used to read the user's mail on their behalf.

What advantages do we get with this approach to authorization?

1. The third-party application never needs to know your Microsoft 365 credentials (username and password)
2. The third-party application can have its access revoked (without needing to change your password or other secrets). Access tokens are relatively short lived and need to be frequently renewed, this allows the user to control revoking the application's permissions preventing new access tokens from being issued.
3. The third-party application only gets permission to a subset of data and actions (e.g. read and write) that you have as a user. The access token can only be used with the permission scopes that the user has consented to. In the example above the application only asked for consent to read the user’s mail. In that case the application could not use the resulting access token to create new or change existing mail. Nor could it use the token to read documents in SharePoint or events in the user’s calendar. Prior to OAuth, whichever third-party application you gave your username and password to would have the full level of access that you had as a user.
4. Access tokens make interactions traceable. OAuth really adds the concept of an application the authorization model. Prior to OAuth, third-party applications would just ask for your credentials and be accessing your Microsoft 365 data as you. There really wasn't a way for Microsoft to know it was you as opposed to an application that you had given your credentials to. OAuth fundamentally changes that and is designed for delegating a subset of access you have to an application. An OAuth token is always bound to an application and to a set of resources and permission scopes. This makes all interactions that access your Microsoft 365 data traceable, and it is discernible when a user accesses data versus an application accesses data on behalf of the user.

There is no need to fear the permission consent dialog!

The permission consent dialog is a transparent way for an application to tell you exactly what data it needs access to and whether it needs to just read that data and/or modify it - there is no need to fear it, in fact we should embrace it! In the past, when supplying our username and password to a third-party application we were really giving the application access to everything we had access to as a user or owner of the data. Modern authorization flips this on its head, now an application only gets the permissions it explicitly asks us for.

The best practice when implementing security is for the application to ask for the minimum level and most specific levels of permission it needs to achieve its functionality, so don't jump to conclusions and fear an application that asks for a large number of permissions over an application that only asks for one or two permissions. An application that asks for very specific permissions is preferrable to an application that asks for high level permissions that give access to a wide range of resources. My advice is to read the permission consent dialog and check that the permissions it is asking for makes sense for the functionality you expect the application to perform. For example if you are using an application that works with your mail then it is reasonable to expect it is going to need mail related permissions to do its job, if however it was also asking for permissions to read your BitLocker keys and read all of your contacts then maybe you have reason to look at the application in more detail before giving consent.

Admin Consent

With Microsoft 365 there is also the concept of Administration Consent. This allows an administrator of the Microsoft tenant to grant an application the permissions it requires on behalf of all users of the tenant. This means that when individual users use the application, they won't be presented with the permissions consent dialog. This is often the preferable approach when deploying applications into an organization to streamline deployment and minimize user confusion and adoption of the application.

OnePlace Solutions products have supported the modern authorization approach for some time, recently we have taken the step of enforcing OAuth based modern authorization across our entire product suite when accessing your Microsoft 365 data and no longer allow older legacy methods.

Although security technology is always changing and modern authorization is a big step forward, a prudent approach is to source your applications from reputable and trustworthy software providers that are committed to ensuring the security of your data.

To learn more about how OnePlace Solutions can help you reach your business goals please contact us.