Microsoft Graph returns 401 for /me/calendars with delegated Calendars.ReadBasic on personal Microsoft account

Peter Holdorf 20 Reputation points
2026-08-25T02:02:49.7433333+00:00

App configuration

  • Supported account type: Personal accounts only
  • Public client / device-code authentication
  • Authority: consumers
  • Delegated Microsoft Graph permission: Calendars.ReadBasic only
  • No client secret or certificate

Observed behavior

  • Device-code authentication succeeds for the intended personal Microsoft account.
  • The isolated Calendar-only authentication state shows Calendars.ReadBasic plus standard protocol identity scopes.
  • A direct request to:

GET https://graph.microsoft.com/v1.0/me/calendars

returns HTTP 401 with an empty response body.

Local diagnostics already completed

  • Request reaches graph.microsoft.com directly
  • HTTPS is used
  • No proxy
  • No redirect
  • Exactly one correctly formed Authorization: Bearer <access_token> header is sent
  • The bearer value is the MSAL access token, not an ID token
  • The dedicated Calendar-only app and token cache are used
  • The older broad-scope app/cache is not used
  • Token is current according to MSAL cache metadata
  • Python requests client

As a control, the same /me/calendars request without an Authorization header reaches Microsoft Graph and returns the normal JSON-formatted HTTP 401 with a Bearer challenge. The authenticated request instead returns an empty 401.

No calendar or event data has been retrieved, and no Microsoft Graph write operations were performed.

Microsoft documentation indicates that delegated Calendars.ReadBasic supports personal Microsoft accounts and is the least-privileged delegated permission for listing calendars.

Questions

  1. Is Calendars.ReadBasic currently sufficient for GET /me/calendars with a personal Microsoft account?
  2. Is there any known issue involving consumers authority + device-code authentication + personal Microsoft accounts + Calendars.ReadBasic?
  3. Is another standard identity/resource scope required for this scenario?
  4. If a fresh reproduction is needed, what exact diagnostic metadata should I capture?

Important limitation: Microsoft Graph request identifiers were observed during the original diagnostic, but their literal values were not preserved in the authoritative evidence, so I am intentionally not providing reconstructed request IDs.I’m troubleshooting a Microsoft Graph authentication issue with a dedicated Calendar-only public-client application.

Microsoft Security | Microsoft Graph
0 comments
Answer accepted by question author
Konstantinos Lianos 825 Reputation points Student Ambassador
2026-08-31T11:20:17.84+00:00

Hello @Peter Holdorf

Hi,

Yes, according to the Microsoft Graph documentation, Calendars.ReadBasic is the least-privileged delegated permission for GET /me/calendars and it is supported for personal Microsoft accounts.

So you should not need to add Calendars.Read just to list the calendars, and no additional identity scope such as User.Read should be required for authorization to this endpoint.

Since the authenticated request returns 401, I would focus on the access token itself. Microsoft documents 401 as meaning that the authentication information is missing or not valid for the requested resource.

For a fresh reproduction, decode the access token locally and verify at least:

aud -> Microsoft Graph

scp -> contains Calendars.ReadBasic

exp -> token has not expired

Do not post the actual token publicly.

I would also test once with a completely fresh token/cache and explicitly request:

https://graph.microsoft.com/Calendars.ReadBasic

If that still produces an empty HTTP 401, capture the following response/request metadata:

request-id

client-request-id

Date

HTTP status

UTC timestamp

App/Client ID

Microsoft specifically recommends supplying client-request-id, response request-id, and Date when troubleshooting Graph calls with Microsoft Support.

I am not aware of a documented requirement for an additional scope in this scenario. If aud and scp are correct and a newly acquired token still fails, this would warrant a Microsoft Graph support investigation rather than increasing the application's permissions.

If this helps resolve your issue, please don’t forget to mark the answer as Accepted / Resolved.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.