Update sample to deal with stricter browser vendor rules for third-party cookies

[jeroenheijmans]

Browser vendors are implementing increasingly strict rules around cookies.
This is increasingly problematic for SPA's with their Identity Server on a third-party domain.
Most notably problems occur if the "silent refresh via an iframe" technique is used.

This repository uses that technique currently, starting with a silentRefresh().
This will fire up an iframe to load an IDS page with noprompt, hoping cookies get sent along to so the IDS can see if a user is logged in.

Safari will block cookies from being sent, prompting a leading OAuth/OpenID community member to write "SPAs are dead!?".
In fact, if you fire up this sample repository on localhost, which talks to demo.identityserver.io (another domain!), and use it in Safari: you will notice that the silent refresh technique already fails!

Edit: starting with Chrome 83, they also have this behavior in Incognito mode.

Several prominent directions for solving this are available, and more too possibly:

1. Run IDS on a subdomain where your SPA is also running (effectively making cookies first-party)
2. Don't use "the iframe technique", but instead use refresh tokens with additional mitigations
3. Switch to a BFF (Backend-for-frontend) setup

I'm not sure yet what route to pick for this sample, if any.

[jeroenheijmans]

Wrote a more detailed blog post about this: https://infi.nl/nieuws/spa-necromancy/

[sathyarajagopal]

Side effect of this is in Chrome incognito mode silent refresh won't work. But when we set "Allow All Cookies" in the settings, silent refresh will start working.

[jeroenheijmans]

Aye, Chrome Incognito (and later on normal mode too) will exhibit this behavior, unfortunately.

[Lonli-Lokli]

Subdomain looks more secure than refresh tokens, right?

[jeroenheijmans]

Unfortunately.... it depends. But in many cases I think the attack vectors for refresh tokens are more impactful than those for subdomains (e.g. the regular flow with redirects involved).

[Lonli-Lokli]

I see just one kind of attack, when eg Okta domain is available under login.example.com - user still able to register under this domain with Okta endpoints, even when only app registration is allowed.

[jeroenheijmans]

I've thought about this issue for some time. And I've also had to deal with the issue in production for some time now. Current status quo seems to be that you just need the warning I already added. I think I will update that section to point to this blogpost where I explain all workarounds and leave it at that.