In previous articles, we explored how applications are registered within Entra ID, and some of the different options around authentication and authorisation. We’ve seen the power that OAuth2.0 can bring in allowing narrowly scoped, delegated permissions, but we need to be aware of the risks associated with allowing these consents.

One of the most common issues that I see in organisations is a lack of control surrounding OAuth2.0 consents, leaving them exposed to an increased risk of unsanctioned applications, or worse, malicious applications masquerading as legitimate ones.

If you’ve not already done so, I’d recommend reading the following articles first to make sure you’re up to speed:

A Quick Recap - What are OAuth2.0 Application Consents?

When an application wants to access a user’s data using OAuth2.0, it first needs to obtain consent from the user. This consent process allows the user to review what ‘scopes’ the application is trying to access and make an informed decision as to whether or not they should be allowing it.

That’s the theory anyway, but in practice, users may not always pay too much attention to what they are granting or who they are granting it to. It may be difficult for them as a non-technical user to fully understand what they are granting access to.

This is where the potential security threats start to creep in.

Risks Associated with OAuth2.0

Whilst OAuth2.0 is great when used securely, it comes with a number of risks. We aren’t focussing on all of these today, but instead we shall consider a few key ones:

  • OAuth Consent Phishing - Attackers can create malicious applications that appear legitimate, in order to trick users into granting access to their data. Once access is granted, attackers can continue to misuse their newly granted permissions to steal sensitive information or perform unauthorised actions.
  • Lack of User Awareness - Users may not fully understand the implications of the consents they are granting. This lack of awareness can lead to unintentional exposure of sensitive data to unsanctioned applications.
  • Over-Privileged Scopes - Applications may request more permissions than they actually need. Users may not notice the excessive permissions and grant access, leading to potential misuse of their data, or a greater blast radius in the event the source application were ever compromised.
  • Revocation Mechanisms - Once consent is granted, it may not be obvious how users can self-revoke these without having been given guidance.

Given these points, we can see why we may want to put some controls in place.

OAuth Consent Phishing - An Example

OAuth consent phishing is where a malicious actor registers their own application and tries to make it look like a valid one the user would use. If the attacker can get the user to consent to these permissions, then they have access to their data.

OAuth consent phishing has increased in popularity over the years, and with a bit of good branding, it can be hard for users to identify. Sure, if the user is savvy, they may well notice that it is an unverified publisher asking for consent, but let’s be honest - how many non-technical users are going to be paying this much attention?

Take the mock-up I created below - do you think your users would spot this is fake if they were presented with it?

Consent Phish

Yes, it clearly says that it is not published by Microsoft in bold, but it has the Outlook logo, it seems to want valid consents that Outlook would want, and we have the trusting, familiar feel of the Microsoft login page. I think it is quite likely that users would click accept without thinking.

Education is Key

One key, non-technical control is education. You need to ensure your users are aware of the risks posed by this threat, and what to look out for. Additionally, you should make it clear how users can revoke access and/or who to contact in the event they’ve inadvertently consented to something they believe is malicious.

Users within the Microsoft ecosystem can visit https://myapps.microsoft.com to view their applications and revoke consents where necessary.

Revoking Consent

User vs Admin Consents

Whilst users can still be tricked into providing consent to a malicious application, keep in mind the scope of this would be limited to them (unless an administrator was tricked into granting tenant-wide consents of course).

Generally speaking, users can only consent to permissions for their own account. Certain higher-privilege permissions may also require administrator consent and can’t just be granted by users.

Even with this being the case, we still need some control.

Controlling Consents

Fortunately, Entra ID provides us with options to put controls in place. Head over to Entra ID > Enterprise Applications > Consent and Permissions as an administrator, and you’ll see a few different options.

Consent Options

Let’s start with the user consent options. Chances are, that unless you’ve already changed these, it is set to “Allow user consent for apps” - the most permissive (and least secure) option. As we’ve seen above, this leaves users a lot more susceptible to phishing attacks and is probably not what we want to be using.

We could go the other way and prevent users consenting to anything by using the “Do not allow user consent” option. Obviously, this is the most secure but will mean users can’t consent to anything - all consent grants will have to be carried out by administrators.

If you operate in a stricter environment, then this may be a suitable option, and it is clearly the most secure option as well. As an administrator, you will have full control over applications accessing user data and can prevent the typical shadow IT and data sprawl you see in many organisations.

Keep in mind however, that if you are trying to add this into an existing environment, you may face some backlash from users who are used to being the masters of their own destiny. This isn’t to say that preventing user consent is the wrong thing to, but it’s important to keep potential backlash in mind and ensure clear communication with your users.

Finally, we have the “Goldilocks” option, positioned between the other two. This is also Microsoft’s recommendation. I’m not sure why it isn’t the default setting—perhaps it is in newer tenants? The option is Allow user consent for apps from verified publishers, for selected permissions (Recommended). As the name implies, this does two things:

  • Restricts consents to verified publishers and internal applications - With this setting enabled, users will only be able to consent to applications developed by their organisation or by verified publishers. Publisher verification is a process operated by Microsoft that aims to ensure organisations are authentic. More details can be viewed here.
  • Restricts consents to “low-impact” permissions - As an administrator, we can classify what scopes we deem to be “low-impact” and only allow users to consent to these. For example, maybe you want to allow some basic permissions that allow OIDC sign-in and basic user information, but don’t want to allow apps to access email or file data.

Low Impact Permissions

What you determine to be “low-impact” will obviously depend on your organisation, its risk appetite and how much freedom you want to allow your users. There are no one-size fits all approaches here.

If you choose to restrict what your users can consent to, you may want to head over to the “Admin consent settings” blade as well.

Admin Consent Settings

Here you can define settings that allow your users to request admin consent for the applications they want to use. This gives them an opportunity to provide some justification for its use and allows an administrator to review before approving.

The users or groups handling these requests do not need to be administrators. However, if they aren’t, they can only block consents and cannot approve them. Global administrator or cloud application administrator role will be required to approve requests.

Summary

Controlling OAuth consents is important to ensure you are sufficiently protecting your organisation and the data that it holds. Being too restrictive can be cumbersome, but there are happy middle grounds to allow users some freedom without significant risk.

It is also worth periodically reviewing the consents granted within your tenant. You can do this through the portal, the CLI, or by using solutions like Microsoft Defender and other Cloud Access Security Broker (CASB) applications.