'Sign in with Microsoft' might be less common than the Google alternative, but that doesn't mean that IT teams running Azure AD (now Microsoft Entra ID) / 365 won't find users granting OAuth access to third party apps. The good news is that Microsoft provides a range of admin tools to manage the risk - here's how to use them.
The longer you work in IT, the fewer things seem to shock you.But one thing that recently blew my mind was how long it's taken Microsoft to crackdown on consent phishing attacks.Duping users into granting access to Microsoft 365 data is as simple as sending a carefully crafted email. A link, using a legitimate technology called OAuth, tricks people into granting access to sensitive data. It's incredibly easy to do.Part of the problem is that up until November 2020, anyone could create a public Microsoft OAuth client (the first step in one of these phishing attacks) with no checks from Microsoft - checks that Google has been doing for years.Although it's taken Microsoft a long time to introduce basic checks, to their credit they have also built some powerful tools for managing OAuth into Microsoft 365 - far superior to what's on offer from Google.I want to share with you the basics of OAuth, and strategies for safely managing this powerful technology with Microsoft 365.
What's OAuth?
OAuth sits behind a popular Single Sign On (SSO) protocol called OpenID Connect.
If you’re not aware of the terminology, you’re probably aware of those “Sign in with Google” buttons that you sometimes see on websites – that’s OpenID Connect.
Google was an early proponent of the technology, but many other vendors support it: GitHub, LinkedIn, Salesforce and Microsoft 365 for example.
OpenID Connect deals with authentication (confirming that you are who you say you are), whereas OAuth lets you authorize other applications to access your data: OpenID Connect is the login part, whereas OAuth is the bit that lets you grant an application access to read your Outlook Calendar, for example:
Think of it as a friend asking to borrow a book from your house, and you giving them a spare key to go and fetch it.
This is extremely powerful and useful, particular in conjunction with core day-to-day tools like Google Workspace or Microsoft 365.
The example we’re using here is Hugo, an application that helps you manage meetings. Letting Hugo access your calendar data means that it knows what meetings you’re having, and (amongst many other things) it can automatically prompt you to define agendas and write up minutes.
What's wrong with OAuth?
OAuth’s strength and weakness can be seen in the spare-key analogy. Giving a spare house key to a trusted friend is very different to giving one to a stranger.
Up until very recently Microsoft carried out no checks: any bad-actor could create a public link that requested access to your Microsoft 365 data and trick people into clicking it. Now, Microsoft at least try to check that the use is legitimate, but it’s not exactly watertight.
If we turn the house key analogy into one about office swipe-cards, you, in the IT team, would probably like to be in a bit more control over who is handing out swipe-cards, and to whom.
Microsoft 365 now gives you the tools to do this.
The Enterprise Applications management console in Microsoft 365
The starting point for OAuth in Microsoft 365 is the Enterprise applications list:
This shows you applications which are connected with Microsoft 365 through OpenID Connect, but also other forms of Single Sign On, such as SAML2.
This is a source of some confusion.
In the world of SAML2, if you delete an application from the list, then users can no longer use Single Sign On to connect to that application. If you remove the association between a user and an application, then that user can no longer login to the application.
This is not the case with OAuth.
There’s two reasons for this:
1) Azure AD (Entra ID) issues ‘refresh’ tokens. These last typically for 90 to 180 days and allow applications to refresh access tokens and regain access.
2) Unless you alter the default Azure configuration, users can simply use OpenID Connect to sign-in again and re-grant access.
Deleting the association between a user and an application doesn’t mean people won’t be able to access the application
In an effort to help, Microsoft offers a broad range of settings to help manage this security risk.
Blocking access
The simplest way to prevent OAuth access going forwards is to go to the User settings blade and set Users can consent to apps accessing company data on their behalf to No.
This is quite heavy-handed as it will block all OpenID Connect access and OAuth tokens being issued and is likely to result in push-back from your users.
Admin approved consent
Microsoft are currently previewing a more subtle approach. Rather than completely blocking access, when a user tries to grant access to data in Microsoft 365, a request is sent to an administrator who can confirm or block the request. This means that you can decide what to do on a case-by-case basis.
To enable this, set Users can request admin consent to apps they are unable to consent to to Yes.
If a user tries to grant consents, they will be asked to enter a reason and further access will be denied until an administrator deals with the request. One or more administrators can be specified and will be notified by email. There’s also a log of requests in the Enterprise Application console.
Scopes
Another subtlety relates to OAuth scopes. Scopes define the sort of access a user is being asked to consent to. This can range from knowing the user’s email address, through to sending emails or even changing configuration settings. The Consent and permissions panel let you allow users to grant access to applications with “low impact” access requests.
If you enabled the recommended setting (Allow user consent for apps from verified publishers, for selected permissions) then you can be reasonably sure that limited data or functionality is being exposed. You can fine-tune the exact scope requests that are allowed using the Permission classifications panel. If used in conjunction with admin consent, it will reduce the number of low-risk approval requests you receive.
Approving or blocking on a per application basis
If you are seeing a lot of requests for a specific application then it might be worth centrally approving all access for this app.
To do this, click on an application in the list and set User assignment required to Yes. Then go to the Users and groups panel, and assign the specific users or groups you want to the application.
Conversely you may want to explicitly block an application. You can do this by setting Enabled for users to sign-in? to No.
You may remember earlier that we said that OAuth tokens can be issued with expiry dates well in the future. If you decide to block an application you should also make sure that Azure expires any refresh tokens.
This isn’t possible through the UI, but Azure provides some Powershell scripts that you can run.
To find these, click on the Permissions panel and then Review permissions. Depending on which radio buttons you choose, various Powershell Scripts are proposed:
Proposed strategy
Based on these settings, we propose a four-point strategy for safely managing OAuth in Microsoft 365 in a low-friction way:
- Grant access to low-risk requests by turning on Allow user consent for apps from verified publishers.
- Set Users can request admin consent to apps they are unable to consent to to Yes in order to safely get a handle on what users are requesting access to.
- For applications that come up repeatedly, assign users or groups en-masse to common applications
Set Enabled for users to sign-in to No for problematic or suspicious applications, rather than deleting them from the application list. Also run appropriate Powershell scripts to clean out any refresh tokens.
.avif)
