Personal Outlook calendar: basic calendar consent succeeds but reads fail

I am investigating delegated, read-only Microsoft Graph calendar access for a personal Outlook.com account. Outlook web calendar opens normally. I want to retain the least-privileged Calendars.ReadBasic permission.

In a private hosted web application, authorization-code exchange and refresh succeed. The requested scope is https://graph.microsoft.com/Calendars.ReadBasic plus offline_access. The application supports organizational and personal accounts and uses the common v2 authority, PKCE, and its registered HTTPS callback. The token endpoint returns the requested calendar scope. Calendar-list and bounded calendarView GETs return empty HTTP 401 responses, including after one successful token refresh.

Application client ID: 015e4286-7db6-4dda-9710-0bf5a311f068. At 2026-11-11 16:45:23 UTC, GET /v1.0/me/calendars?$top=1&$select=id returned 401 with request-id 2ddbea43-7cc9-42c6-9081-e26f80072262. A standard /v1.0/me/calendarView request returned 401 with request-id e03ed9bb-1e3f-4bf0-a5b6-45a265b442fe. Both authorized responses had empty bodies and no authentication challenge. An unauthenticated control returned normal JSON InvalidAuthenticationToken and a challenge.

I then signed the same personal account into Microsoft Graph Explorer in Edge. Graph Explorer showed Tenant Personal. I consented only to the additional Calendars.ReadBasic permission; the UI showed Scope consent successful and subsequently an Unconsent/Reload control for that permission. The profile baseline succeeded. The exact calendar-list GET nevertheless returned HTTP 403 ErrorAccessDenied. Reloading that permission and refreshing the Graph Explorer page did not resolve it. The last corrected calendar request was observed before 2026-11-11 18:03:23 UTC; an exact response timestamp was not captured.

Graph Explorer request-id: 15e9f9f8-f7a4-4968-820e-1ca0646d8e81. Client-request-id: 240d8a1e-708f-4b8d-8808-42eef4987188. The response was Microsoft.Exchange.Services.OData.ODataAuthorizationException, with an inner Microsoft.Exchange.OAuth.Core.InvalidOAuthTokenException. It listed Calendars.ReadBasic among acceptable calendar permissions but reported that the application only had User.Read granted. Thus the tester did not establish an effective calendar token, despite its successful consent UI; I am not claiming this proves an account or service defect.

What explains the consent/effective-permission mismatch for this personal account, and what supported least-privileged diagnostic can distinguish token acquisition, registration, and account/mailbox authorization issues? No tokens, client secrets, passwords, account addresses, calendar contents, or calendar-write permissions are included in this report.