When should we drop the SSO access token?

Question

TL;DR - How do we expire the access token when the user signs out in another tab?

Details:

In the SSO documentation it says:

When to call the method

If your add-in cannot be used when no user is logged into Office, then you should call getAccessToken when the add-in launches and pass allowSignInPrompt: true in the options parameter of getAccessToken.

That's nice and clear. But when should we stop using the token? Is there an event we can use to know the user signed out? (I haven't been able to find one.)

I ask because the token continues to work even when the user signs out in another tab. So if we keep the token for any length of time, it leaves scenarios open where the user's account is used incorrectly. For instance:

1. User signs in
2. User opens the add-in; add-in grabs an access token and keeps it
3. User opens another tab
4. User signs out of their account in that other tab
5. User steps away
6. Someone else uses the add-in to do something they shouldn't

I just did that (well, not Step 6), and the access token continued to work in the tab with the add-in. Yes, the user probably should have closed the tab when they signed out. And yes, they shouldn't leave their computer unlocked either. But I'd like to expire the token in that situation.

Here's another that's a bit easier to see happening:

1. User signs in
2. User opens add-in
3. User realizes they need to switch accounts. Since you can't do that in Web Excel, they do it in another tab
4. User tries to use the add-in — and it's using the old account, not the one the switched to

We were just acquiring the token every time we needed it, but we recently started running into rate-limit issues. So now we're caching it briefly, but figuring out how briefly is tricky, particularly given scenario #2 above. We want to avoid the rate limit, but not leave the window open too long. Knowing when the user signs out (without hitting a rate limit) would let us do that.

Tabasco

Answer 1

Because of the perceived rate limit we were experiencing at the time I posted the question, we settled on caching it for one minute and ensured that we never had overlapping calls to getAccessToken in our code. That's worked well these past couple of years. But the other day I noticed that the documentation (now) says:

Don't cache the access token

Never cache or store the access token in your client-side code. Always call getAccessToken when you need an access token. Office will cache the access token (or request a new one if it expired.) This will help to avoid accidentally leaking the token from your add-in.

So either I missed that in 2020 or it's been updated since (obviously I tend to think the latter, but hey, we all miss things).

It's possible what we thought was a rate limit was in fact the platform not allowing overlapping calls or not handling them properly. We dealt with that by ensuring calls to getAccessToken were serialized using a wrapper function along these lines.

let lastPromise = Promise.resolve("");
function getToken() {
    return lastPromise = lastPromise
        .catch(() => {}) // We don't care if the _last_ one failed, just that it settled
        .then(() => OfficeRuntime.auth.getAccessToken());
}

Tabasco