Can I acccomplish single-sign-on with disparate top level domains?

[niklasenskog]

Which version of Duende IdentityServer are you using? 7.0.4

Which version of .NET are you using? net8.0

Question I have our provider at let's say login.acme.com, and two web clients (at foo.acme.dk, foo.acme.se + bar.acme.dk and bar.acme.se). Currently I'm using the CookieAuthenticationDefaults auth scheme.

With the impending death of the third-party cookies and an IdP at a different top level domain from the relying parties, is it still possible to enable single-sign-on (and -out) for these two clients?

Moreover, I have a phone app serving the same users, that I would like not to be included in the SSO setup.

So, if I'm logged in to the phone app, and suddenly decide to log on to https://foo.acme.com for reasons, with a quick detour to https://bar.acme.com to before I logout (from either web app), I would like to be logged out of both web apps, but not the phone app.

From what I've gathered in this forum, separating a client from single-sign-on would require a secondary logical provider, with separate sessions. But still, should a user name or password be updated, or a user retired, I would want the user to be evicted from all these application sessions.

That's all I want really :-)

1. I'm thinking this should all be possible, right?
2. Hints on what I roughly need to do would be fantastic!
3. What license level is required?

Additional context

General client config:

Property	Value
ProtocolType	oidc
RequireClientSecret	1
RequirePkce	1
FrontChannelLogoutSessionRequired	1
BackChannelLogoutSessionRequired	1
AllowOfflineAccess	1
IdentityTokenLifetime	300
AccessTokenLifetime	3600
AuthorizationCodeLifetime	300
RefreshTokenUsage	1
RefreshTokenExpiration	1

[RolandGuijt]

I'm having difficulties with understanding what exactly you're asking.

The way I read it is that there are 2 questions:

• Is there a way to do single sign on across 2 different IdPs?
• Is there a way to exclude a phone app from single sign out across 2 different IdPs?

Are these assumptions correct? If so, my first question to you would be: why would you need multiple IdPs?

[niklasenskog]

Sorry for that, please let me try that again:

My objectives are to serve my user base in the following ways

• Users should benefit from SSO on web apps foo and bar, on a finite set of of top-level domains, let's say .se and .dk for the sake of argument
• Users on my phone app, phoneapp let's say, should not be affected by the sign in status of the other two apps
• Any updates to account credentials should require reauthentication, on either of the three apps

So users logging out from foo should find themselves logged out from bar as well, but not from phoneapp. However, I still want to be able to drop their session in all apps, for instance when a user name or password is updated.

That's my target. And thanks to a common Authority setting between the apps, and fairly short-lived access tokens (with all refresh tokens revoked on logout), users are enjoying SSO for now.

But since my IdP top-level domain is different from those of my apps, I'm thinking my IdP cookie will be blocked from my apps with the rest of the third-party cookies in the fairly imminent future, right?

So, my kneejerk reaction to blocked cookies is to map the .se and .dk domains to my IdP with DNS records. Which would require my users to log in twice, if they for some reason want to visit foo.se and foo.dk. Not fantastic.

Question 1: how can I do better than that? Question 2: are there any license model requirements for exposing my one IdP through multiple top level domains?

As for the phoneapp, I guess I would isolate them from the signout by not deleting the refresh tokens of that particular client, when users log out from either of the other two apps. So maybe I answered that one myself.

Hope I made things clearer!

[josephdecock]

Third party cookie blocking is a concern for SPAs that perform the protocol flows in the browser because many of the techniques used in that context involve creating a hidden iframe to the identity provider, and then rely on the requests in that iframe to send cookies along with the request to the identity provider. Third party cookie blocking stops those cookies from being sent. However, more traditional web applications that are rendered server side don't use those techniques and 3rd party cookie blocking doesn't impact them. The way to overcome this problem in a SPA is to pair it with a backend server called the backend-for-frontend or BFF. Browser based applications with tokens accessible from the browser has historically been a huge source of security problems. The BFF architecture removes those security problems from the design. Our recommendation for SPAs, in line with the guidance from the standards bodies, is to use the BFF pattern both to prevent 3rd party cookie blocking from breaking things, and to greatly improve the security of your system. We have a library for implementing this pattern - see more info here. Our BFF library is included in the Business and Enterprise license tiers.

For the requirement that when the user updates their password, you want to end their session at the various client applications, I'd recommend using server-side sessions. With server side sessions, you'll have the ability to query for all the user's sessions, even across devices, and end those sessions. See here for more details.

Finally, it sounds like you have things working for your phone app, but feel free to follow up on that if necessary.

[niklasenskog]

Great, thanks to the both of you, we'll look into heading over to server side sessions and the Duende BFF library then!