[BUG] Office online throttling calls to Office.auth.getAccessToken()

[celluj34]

Calling Office.auth.getAccessToken() repeatedly on Excel Online throws "API has been throttled, code 13013" error.

The desktop version does not have this limitation, and is the recommended approach from Microsoft: https://learn.microsoft.com/en-us/office/dev/add-ins/develop/sso-in-office-add-ins#dont-cache-the-access-token

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: Office Web
• Host [Excel, Word, PowerPoint, etc.]: Excel
• Office version number: O365
• Operating System: Windows 10
• Browser (if using Office on the web): Firefox 112

Expected behavior

I expect to get a valid token.

Current behavior

An error gets thrown.

Steps to reproduce

1. Open an Excel sheet
2. Call await Promise.all([Office.auth.getAccessToken(),Office.auth.getAccessToken(),Office.auth.getAccessToken(),Office.auth.getAccessToken()])
3. See error

Link to live example(s)

n/a

Provide additional details

n/a

Context

We only noticed this issue after we stopped separaretly caching the access token yesterday.

Useful logs

Thank you for taking the time to report an issue. Our triage team will respond to you in less than 72 hours. Normally, response time is <10 hours Monday through Friday. We do not triage on weekends.

[ghost]

Thank you for letting us know about this issue. We will take a look shortly. Thanks.

[t4rzsan]

We are seeing this as well. The error occurs after exactly 4 calls to getAccessToken. It seems that it only happens on Outlook desktop for Windows and for macOS. We have been unable to reproduce the error on OWA.

[ruijiaMS]

Hi @celluj34,
Thanks for reaching out to me, we can not repro this issue now. Could you please provide more information about the full code or a recording video?

[celluj34]

@ruijiaMS the full code is posted in the screenshot above. I am typing this into the Developer Tools > Console:

await Promise.all([Office.auth.getAccessToken(), Office.auth.getAccessToken(), Office.auth.getAccessToken(), Office.auth.getAccessToken(), Office.auth.getAccessToken(), Office.auth.getAccessToken()]);

I have a custom add-in, so I am opening the console directly from the taskpane.

[t4rzsan]

Thanks for looking into this.

I have created a small sample the reproduces the error. See the attached gif. It fails on call number 6 every time on Windows and on Mac. OWA shows no errors.

This is the JavaScript:

function getToken() {
    return new Promise(function (resolve, reject) {
        {
            Office.auth.getAccessToken({
                allowSignInPrompt: true
            })
                .then(function (token) {
                    return resolve(token);
                })
                .catch(function (error) {
                    reject(error);
                });
        }
    });
}

let counter = 0;

function testToken() {
    counter++;

    getToken()
        .then(function (token) {
            console.log(counter);
        })
        .catch(function (error) {
            console.error(error);
        })
}

[ruijiaMS]

Hi @celluj34, @t4rzsan,
Thanks for reporting this issue. It has been put on our backlog<Bug#7805994> for internal track.
Any update will post here!

[ruijiaMS]

Hi @celluj34 @t4rzsan，
I reach out to related team and they confirm this error message is a basic mechanism in causes and handling of errors from getAccessToken. To help customers understand what these error means and then improve usage, we have documented for some errors, including throttling 13013 in https://learn.microsoft.com/en-us/office/dev/add-ins/develop/troubleshoot-sso-in-office-add-ins#13013.

[celluj34]

Yes, I am aware of the definition of the error, however it is Microsoft guidance to call it when necessary. We were previously caching the token ourselves until we found this information, and it works beautifully on desktop, but this error happens in Office online.

[ruijiaMS]

@celluj34 Thanks for your comment!
The api in desktop is not identical with that in Office online, which means that we have similar implementation for these two platforms but still existing differences to some degress. Your feedback is very meaningful for us and we've heard similar feedback from other developers. We will definitely reach out to the related team to consider for improvements.

[NWessel]

I have the same issue with an excel add in that i'm running on the desktop

and as @celluj34 said

[fzumstein]

What's the status on this? I am seeing the same issue on every platform (macOS/Windows Desktop and Web): after the 5th invocation it returns Error 13013: This API has been throttled to slow the call frequency. The instructions (screenshot in @NWessel's comment) are giving very strong instructions to never store the access token.

[ruijiaMS]

The team will review this work item on their planning. We unfortunately have no timelines or update to share at this point. Any update will post here.

[NWessel]

A few months have passed now and I need to start developing a new application for another client.
What is the recommended approach? Should we still not cache it? Is the throttle fixed? @ruijiaMS

[fzumstein]

Yup, just getting this acknowledged whether it's an actual bug, a docs issue, or if we are using it wrong would be appreciated. CC @keyur32

[catmanjan]

bump

[gwmensink]

I'm running into the same issue. It would be very much appreciated how we are expected to move forward.

[yathk]

We're experiencing the same issue on the Outlook Windows Version 2310, with the addin sideloaded. The token doesn't seem to be cached, and if getAccessToken() is called multiple times a 13013 error is returned, with the message: "This API has been throttled to slow the call frequency". Is there any update with this? Please let me know if you need any other information...

[krisrm]

This is a problem for us, Outlook version 2302. Similar results as @yathk ; calling getAccessToken() multiple times seems to cause an error. An update on this one is needed urgently, as it's preventing us from authenticating calls made from our add-in.

[celluj34]

This is a problem for us, Outlook version 2302. Similar results as @yathk ; calling getAccessToken() multiple times seems to cause an error. An update on this one is needed urgently, as it's preventing us from authenticating calls made from our add-in.

If you need a quick answer, just cache it in sessionStorage and check the expiration yourself. I used jwt-decode with some date trickery to math the expiration and it's been working just fine.

[yathk]

@celluj34 Thanks for the tip :) Yes, I'm caching it now in OfficeRuntime.storage, but this obviously goes against what Microsoft recommends in their docs.

[krisrm]

@celluj34 I'm sure this works, but I don't see a good way to do this securely from the add-in context. OfficeRuntime.storage and sessionStorage are not great. It would be much better if Microsoft provided a fix to this call that used a secure cache, as the documentation suggests.

[celluj34]

@krisrm Even if it could be stored securely, it's still sent plaintext in the http request, which can be read from the Network tab of the Developer Tools. JWTs aren't meant to be secret, their value comes in being verifiable.

[krisrm]

@celluj34 an XSS attack would be able to pull the token and impersonate the user to your API; the internet is littered with articles explaining why you shouldn't use sessionStorage or localStorage to store JWTs.

[celluj34]

@krisrm if you have a better solution, I'm all ears.

[NWessel]

This is what I ended up doing for now, got frustrated with the no guidance - Should be easy to remove the inmemory variable if this is ever "fixed"

[DanielSchwabeDocuware]

Are there any news on this Bug? We experience the same issue for our Outlook addin. Office Web works, but we can easily reproduce the bug on the Outlook Fat-Client on Windows.

[marcus905]

We have the same bug and situation as @DanielSchwabeDocuware here.

[mrodrigs]

Experiencing the same bug in Excel Desktop

[dhwanilc]

@ruijiaMS - We are continually experiencing this in our desktop client. Outlook add-in documentation recommend not doing any caching of token on our side. Any fix or update on the issue?

[adscreen]

I am also currently developing an Outlook add-in and have encountered the same error. I hope there will be a fix for this soon, the issue has been open for over a year now...

[dhwanilc]

I opened an ICM with the msft add-in team and they recommend we can work around the throttling by not passing "allowConsentPrompt / allowSignInPrompt" to the auth options.

[adscreen]

Hello @dhwanilc Thank you for your answer. It now works without the error.