Guest user: Authentication every x hours (For API ) and works when opening via Sharepoint

Question

When I authenticate using OAuth API and generate an acess token and then hit the get by shared url api, this give me

{
"message" : "There has been an error authenticating the request.", "error" : { "backingStore" : { "isInitializationCompleted" : true, "returnOnlyChangedValues" : false }, "message" : "There has been an error authenticating the request.", "fieldDeserializers" : { "details" : { }, "innerError" : { }, "code" : { }, "message" : { }, "target" : { } }, "additionalData" : { }, "code" : "accessDenied" }, "fieldDeserializers" : { "error" : { } }, "additionalData" : { }, "suppressed" : [ ], "localizedMessage" : "There has been an error authenticating the request." }

And then i login via UI and then hit the API with the same Access token it works. This happend every x hours.

Is there something on my tenant/external tenant where I have been invted should check?

Answer 1

Access tokens expire typically in an hour. There is no sliding interval where use extends the lifetime. Once expired you need a new token. A common approach is to allow refresh tokens which last longer. When the token expires, you can use the refresh tokens which last to get a new access token.

note: if you are using a client secret, then refresh tokens are not used. You just check if the token is expired before use, and get a new token if required

Answer 2

Hi,

It sounds like your access token itself is valid, but the call is being blocked by a policy or user context requirement in the tenant, especially since it starts working as soon as you sign in via the SharePoint UI. This pattern lines up with Microsoft Entra (Azure AD) Conditional Access session controls, such as sign‑in frequency, which can override default token lifetimes and require users (including guests) to reauthenticate after a configured interval.

A few things to check:

1. Conditional Access / sign‑in policies

In the tenant (and in the external tenant where you’re a guest), ask an admin to check Entra ID → Security → Conditional Access for any policies that:

• Require MFA
• Require a compliant device
• Enforce a sign‑in frequency (e.g. reauthenticate every X hours)

Microsoft’s docs explain that these session controls apply to cloud apps like SharePoint Online and Microsoft Graph and can force reauthentication after a set window(see Manage Conditional Access session controls). In practice, that means non‑interactive API calls can start failing with accessDenied until the user does another interactive sign‑in in the browser.

2. Guest user behavior

Since you’re a guest in another tenant, confirm:

• That your guest invitation has been accepted and the account is fully set up.
• Whether that tenant has specific Conditional Access rules for guest users, or expects guests to sign into SharePoint at least once before programmatic access works.

Guest accounts are subject to the same Conditional Access and session policies as internal users, so sign‑in frequency and other session controls can also force guests to periodically reauthenticate via the browser before delegated API calls will succeed (again, see the Conditional Access session lifetime and sign‑in frequency docs linked above).

3. Token details (to rule out simple issues)

Decode your access token and check:

• aud = https://graph.microsoft.com if you’re calling Graph, or https://{tenant}.sharepoint.com if you’re using the SharePoint REST API directly.
• scp / roles include the expected file/SharePoint permissions.

If there is a sign‑in frequency Conditional Access policy, the behavior you describe (API works for some hours after visiting the site, then only works again after logging in via UI) is expected. In that case, you’ll need to either:

• Have an admin adjust the Conditional Access / session policy for this scenario, or
• Ensure your application uses an interactive OAuth flow that can satisfy Conditional Access requirements and then rely on refresh tokens within that window. Microsoft’s developer guidance for Conditional Access describes how apps using OAuth/OpenID Connect are expected to handle these policies.

Hope this helps.

Answer 3

Thanks for confirming. To move forward, can you check a few things:

1. Get the raw Graph error details

The SDK message “There has been an error authenticating the request.” is very generic.

For a failing call, please capture the raw HTTP response from Graph (body + headers), especially:

• error.code
  • error.message
  • error.innerError (including any request-id and date)
  With the request-id and timestamp, an admin in the external tenant can look up the exact reason in Entra / SharePoint logs.

2. Compare tokens before and after visiting the site

When the API fails and then later works:

• Copy the access token you use before visiting SharePoint (failing call).
  • Copy the access token used after visiting SharePoint (working call).
  • Decode both at https://jwt.ms and compare iat, exp, tid, oid, scp/roles.
  • If they’re different, the browser visit is causing a new token or new claims that satisfy a policy.
  • If they’re truly identical and one call fails while a later one succeeds, then the change is likely in SharePoint’s handling of your guest/session, not the token itself.