Angular-auth-oidc-client: Silent renew in Chrome incognito

[benjaminandresen]

Hi
Silent renew seems to be broken when using latest version of Chrome (83.0.4103.97) in incognito mode. Identity server returns login_required for all renew requests.
Works outside incognito, tested on several clients.
Brgds Benjamin

[jeroenheijmans]

Chrome 83 did indeed start blocking "third party cookies" in Incognito mode, following Safari which is already doing that in normal mode.

You are most directly affected if your Identity Server lives on a domain different from where you serve your SPA. This includes running on respectively (for example) https://demo.identityserver.io and http://localhost:4200 (at least I think localhost is _not_ exempt from this).

This will break things like iframe-based silent refresh, but also other mechanisms that rely on the cookie and iframes.

Not much the library can do for you here probably. You as an application developer will need to rethink your login flows in SPAs. Some directions for solutions/workarounds include switching to "BFF Architecture", using refresh tokens (with needed precautions/mitigations!), or fixing up the (sub)domain e.g. via DNS where your IDS and SPA are hosted.

[Miboch]

Will hosting the identity server and SPA on separate sub-domains on the same domain circumvent this restriction? Herein I'm imagining a setup akin to the following:

SPA url: sub.domain.tld?
Identity url: identity.domain.tld?

[damienbod]

still separate domains...

• Use the same domain with a BFF (Same domain) (cookie with server authn)
• use refresh tokens, but this is not so safe, server implementations for this are not supported in most STS, no revocation endpoint, single usage, rotation and so on.
• avoid safari

guessing that with time a solution will be found for this but at present no battle tested solutions exist.

[jeroenheijmans]

SPA url: sub.domain.tld?
Identity url: identity.domain.tld?

@damienbod you responded:

still separate domains...

I'm hesitant to ask, since you are an absolute authority in this IDS domain... but: are you sure this would never work?

The reason I ask is because at this very moment my team actually has a running setup like this:

• https://ids.example.com running IdentityServer4 on Azure
• https://app.example.com running an Angular application

and the Angular application can use the "Silent Refresh via iFrame" technique in latest Safari on OSX, and Chrome 83 incognito on Windows 10 (so the /connect/authorize?....prompt=none call in an iframe properly does send the cookie for ids.example.com along). Just now verified that in both setups that it does work (I think), as we got scared for a moment here that this "subdomain setup" would not be viable...

We are still on Implicit Flow though, considering switching to Code+PKCE later on - should that matter.

Do I have a different context? Or are there upcoming changes you know of where even that will break?

[benjaminandresen]

Thank's for the explanation!
We'll try to solve it by setting a domain cookie on our identity server, and run all spa's on subdomains under the same SLD as the identity server.
Shouldn't this be viable, when setting an explicit domain for the auth cookies?

[damienbod]

@jeroenheijmans If Safari allows sub domains, then it is ok, I never tested this. iframe for Implicit flow and code flow is all the same, this should not matter. I have not read up in detail about the upcoming changes to Safari and Chrome, or know when this is coming.

Greetings Damien