OAuth Entity Scopes

Richard Hine
Tera Guru
Tera Guru

Hi,

**Disclaimer I am by no means an expert in OAuth**

I am currently integrating with some of the Microsoft Threat Protection and 365 Defender APIs. Running a 365 Defender Advanced Hunting query requires permission AdvancedHunting.Read.All which the azure registration has.

When I run the query it fails telling me that permission AdvancedQuery.Read.All is required. This is part of Window Defender ATP permissions.

The issue I have is that AdvancedHunting.Read.All is part of scope https;//api.security.microsoft.com/.default

AdvancedQuery.Readl.All is part of scope https://securitycenter.onmicrosoft.com/windowsatpservice/.default

The OAuth application registry allows definition of more than one scope and these can be chosen in the OAuth Entity Profile.

The OAuth Entity profile also allows for multiple scopes,

find_real_file.png

but when attempting to retrieve a token for the credential this fails :-

find_real_file.png

My question is, should it be possible to have more than one scope in a token and if so does anyone know why this is failing? I am not sure if this is a bug in SN or if it should not be possible.

N.B. It works fine with only one scope in the entity profile but then I don't have the full collection of roles required to run the API.

Any help would be gratefully received,

Richard

1 ACCEPTED SOLUTION

Richard Hine
Tera Guru
Tera Guru

Just as a follow up to this, you can only have one scope in a Microsoft token, the error was being generated on the MS side and there was no issue with ServiceNow.

The issue was resolved by correcting the 365D URL, there was a mistake in the context I had been supplied; once that was corrected, only the D365 scope was required.

Thanks,

Richard

View solution in original post

1 REPLY 1

Richard Hine
Tera Guru
Tera Guru

Just as a follow up to this, you can only have one scope in a Microsoft token, the error was being generated on the MS side and there was no issue with ServiceNow.

The issue was resolved by correcting the 365D URL, there was a mistake in the context I had been supplied; once that was corrected, only the D365 scope was required.

Thanks,

Richard