Graph /shares endpoint returns 401 for Guests until I force a 403 on /groups - Why does this fix it?

Hi everyone,

I am encountering a bizarre authorization behavior with Microsoft Graph API involving External Guest Users (B2B) accessing SharePoint Online files. I have isolated the issue to a specific sequence of calls that suggests a "Just-In-Time" permission or session-hydration lag, but I can't explain why a specific error fixes it.

The Scenario

User: External Guest (B2B) invited to the tenant.
Auth Flow: Delegated Permissions (Token contains Files.Read.All, Sites.Read.All, User.Read.All).
Action: Attempting to resolve a sharing link (encoded) via the /shares endpoint.
Context: The user has been granted access via "Specific People" sharing.
Environment: Fails consistently in Production, works perfectly in a Lab tenant.

What I have already ruled out:

Lockdown Mode: "Limited-access user permission lockdown mode" is NOT active on the site collection.
User Info List (UIL): The Guest User exists in the Site User Information List with the correct claims identity (i:0#.f|membership|...). I have manually verified the entry is correct and not a "decoy" email-only entry.
Conditional Access: The token has valid MFA claims (amr: mfa) and acrs: p1.

The Anomaly (The 401 -> 403 -> 200 Pattern)

Step 1 (The Goal): GET https://graph.microsoft.com/v1.0/shares/u!{encoded_url}/driveItem
- Result: 401 Unauthorized (Code: accessDenied).
- Note: Attempting a direct call to /drives/{id}/items/{id} with the same token also returns 401.
Step 2 (The "Voodoo" Fix): GET https://graph.microsoft.com/v1.0/groups/{random_group_id}/drive
- Target: A Microsoft 365 Group the user is NOT a member of.
- Result: 403 Forbidden (As expected).
Step 3 (Retry Step 1): GET https://graph.microsoft.com/v1.0/shares/u!{encoded_url}/driveItem
- Result: 200 OK.
- The API now successfully resolves the link and returns the file metadata. This access persists for several hours before the cycle repeats.

My Analysis

Since "Lockdown Mode" is disabled and the user is present in the UIL, I suspect the /shares (and /drives) endpoint is hitting a legacy authorization stack that perceives the guest session as "stale" or "unverified" for the specific site resource.

The /groups endpoint interacts with the modern Unified Groups infrastructure. My theory is that hitting this endpoint forces a JIT (Just-In-Time) refresh of the user's security context or group membership claims against Entra ID. This side-effect seems to "warm up" or side-load a permission cache that the legacy SharePoint stack requires to authorize the request.

The Question

Has anyone seen this 401 -> 403 -> 200 pattern before? Is there a known "hidden" cache or synchronization process that the /groups endpoint triggers which /shares does not?

I am looking for a cleaner way to initialize this context than intentionally triggering a 403 error in my application logic.

Any insights would be greatly appreciated!