ox1ygen avatar image
0 Votes"
ox1ygen asked FrankHuMSFT-3200 commented

SignIn Events Azure AD Graph API wrong next link


I understand that MS Graph API would be a proper way to do it, but I still have to use Azure AD Graph API. So, I put my request for signInEvents at It works as I got my events. The response contains

"@odata.context": "$metadata#signinEvents"

value: []

"@odata.nextLink": ""

It is not possible to use the next link because it doesn't work. If you replace with as in my original request it works as expected. I don't think that it is a proper workflow to change the next link every time. Is it a bug?

I have tested it with my own application. Firstly, I have assigned delegated permissions, then I removed them and assigned application permissions.

- Azure Active Directory Graph (Directory.Read.All)
- Microsoft Graph (Directory.Read.All)

With delegated permission assigned I have got an exception "AADSTS65001: The user or administrator has not consented to use the application"

With application permissions assigned I have got an exception Authentication_ApplicationHasNoDirectoryReadAccess

All requests to were successfully performed.

What kind of permissions do I need to have then? And how I should use this "" next link?

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

FrankHuMSFT-3200 avatar image
0 Votes"
FrankHuMSFT-3200 answered FrankHuMSFT-3200 commented

how are you getting your access token? It seems like when you're utilizing a flow that's most likely client credentials as it sounds like you're not getting the delegated permissions, but the application permissions. For more information on permissions I suggest taking a look here :

In addition to that, per your response the AAD Graph API is being deprecated and not supported anymore. If you'd like to get the next page feature working, please utilize the microsoft Graph API.

If you'd like there to be further support for the AAD Graph API please submit your feedback here : and if there's enough community support the product team will look into putting this on the roadmap for the future.

You could also file a support ticket to see if you can get this enabled/supported for your specific scenario.

- Frank Hu

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@FrankHuMSFT-3200 Thank you again for a quick response! Well, in case of using delegated permissions I use this config:

  1. "grant_type": "password"

  2. "username": "username"

  3. "password": "password"

  4. "scope": "openid"

  5. "resource": "resource"

I use this configuration according to the documentation. It works just fine. I can successfully get a pair of tokens to the resources my application has permissions for. My role is a Company Administrator.

I performed an experiment using a well-known id "a0c73c16-a7e3-4564-9a95-2bdf47383716" for Microsoft Exchange Online Remote PowerShell using the above mentioned config and it worked. I obtained an access token for resource: "". So, what is the difference? What is that specific permission or right I have to provide my app with to successfully repeat that behavior?

0 Votes 0 ·

hey @NikitaKrivets-9470,

The well known id is a term meant for OIDC configs.

The ID you are using is the App Identifier for the app registration for your msft exchange online remote powershell which has already had permissions granted by some gobal admin to access This is a unique application registration as it's meant for a Microsoft first party application.

Your application already has the correct permissions and this is looking like an issue with the MSFT Graph API thanks for letting us know about this, I'll look into this further and see if we can get this issue resolved as soon as possible. Thanks!

1 Vote 1 ·