getTokenSilentlyEquivalent that avoids third party cookies - oauth-2.0

Question

I wrote a cypress plugin that helps to simulate auth0 for testing without having to go through the whole redirect to and from the login pages.
It uses silent authentication or getTokenSilently to avoid the redirects etc.
return new Cypress.Promise((resolve, reject) => {
let person = atom.slice(Cypress.spec.name, 'person').get();
assert(!!person && typeof person.email !== 'undefined', `no scenario in login`);
auth0Client.getTokenSilently({ ignoreCache: true, currentUser: person.email, test: Cypress.currentTest.title })
.then((token) => {
log(`successfully logged in with token ${JSON.stringify(token)}`);
resolve(token);
}).catch((e) => {
console.error(e);
reject(e);
});
})
The auth0 docs appear to be saying that silent authentication is not the preferred way for single-page applications.
This post Refresh token rotation does not suggest an alternative to getTokenSilently that does not use third-party cookies.
If I look at the source code in #auth0/spa-js, getTokenSilently still appears to use cookies, even if you have
scope: "offline_access",
useRefreshTokens: true
I am confused as to what is an alternative to getTokenSilently that does not use third party cookies.
getTokenSilently also does not currently work in safari because of this reason.

Answer 1

SECURED SPA TESTS
The simplest all round option might be to do a full redirect at the start of your test suite, as in this Curity code example, which uses Cypress tests. This has the advantage that the SPA can call real APIs afterwards. It will also work in all browsers including Safari. It is probably the option I would use.
GETTING MOCK TOKENS IN CLIENTS
I like your mock plugin idea, since at times it is useful to be able to bypass some of the Authorization Server behaviour, if it gets in the way of testing.
It feels like infrastructure that you cannot control is getting in your way though. Perhaps your plugin should not need to depend on client side SDKs. Maybe you could just have a mock getTokenSilently that issues its own tokens using a JWT library?
Token issuing code
It depends though on what you want to do next, eg do you want to call real APIs? If so then the Secured SPA Tests option might be simplest.
USING MOCK TOKENS IN APIs
One useful technique to be aware of is the Wiremock tool, which can register canned responses with tokens base on tokens you've issued in your own test code. Here are some API tests of mine that use this approach.
In my case the API requires user level tokens and a code flow by default. These tests enable a more productive API development setup, where the API code validates mock tokens in the standard way. It may not be such a good fit for SPA tests though.
SILENT REDIRECTS
In a real SPA, getTokenSilently relies on the Authorization Server's (third party) SSO cookie. A code flow is run on a hidden iframe to get new tokens, using OpenID Connect's prompt=none request parameter. This does not work in the Safari browser with default settings, since it drops the SSO cookie, as part of an initiative to prevent third parties from tracking users.
BACKEND FOR FRONTEND
To solve the above problem in a real SPA, the current best practice is to use first party cookies instead of relying on the SSO session cookie. An SPA running at https://example.com can use an API at https://api.example.com to enable this. More on this theme in the Token Handler Pattern.