Identity Server Issued Cookie and Server Side BFF Sessions

[janmchan]

When a user logs in, whether it is using BFF or out of the box blazor authentication, they get issued 2 Identity Server related cookie, the authentication cookie (application.identity / idsrv) and the idsrv.session. Usually, the expiry of persistent authentication cookie is set globally for all application (i.e. 14 days) and for front end framework (e.g. blazor), the cookie is refreshed through the silent login process regardless of the refresh token which can have a per client lifetime.

My question is the Identity Provider authentication cookie still relevant if I start using BFF with server side session support? I understand that if the session is managed by the server side BFF, then it will determine whether the user's session is still valid based on the application's own cookie and if the refresh token is also still valid. Also, if there is any interaction between the BFF server and Identity Server, it would be through the backend.

[RolandGuijt]

Yes, the identity provider authentication cookie is still relevant since that makes single signon possible.
When users open other applications that are also clients of the identity provider, they don't have to login again.
There are also other uses for it: for example when a page, present on the identity provider, is used to revoke refresh tokens. (Which we include in our UI templates too).

[janmchan]

Thank you @RolandGuijt. So from the sound of it, the other uses are more of SSO related.

One example scenario is the current Identity Server Server Side implementation has a bug where it doesn't update the actual cookie. So even though someone can have a refresh token let's say 1 year, the Identity Server cookie itself remains the default expiry (i.e. 14 days).

ASP.NET sliding cookie expiration logic breaks with server-side sessions and a persistent cookie · Issue #1417 · DuendeArchive/Support

But in terms of the session relative to the current application if it implements BFF, it should not be directly be affected by the Identity Server Issued Cookie. So I'm assuming that if the cookie was for example to physically expire (e.g. persistent), but the user is still active in the client application, that the user should get logged out as long as their session is still active.

[AndersAbel]

That bug is fixed and planned for the upcoming 7.3.0 release: DuendeSoftware/products#1622.

[RolandGuijt]

Couple of things to keep in mind here:

• The access/refresh token is separate from the session cookie mechanism (unless their lifetimes are synced with the CoordinateClientLifetimesWithUserSession option)
• There are n+1 sessions where n is the number of clients and the +1 is IdentityServer's session.

So:

• Changing the lifetime of the IdentityServer session doesn't by default affect the refresh token lifetime.
• When IdentityServer's session expires, client sessions can very well be still active. The client itself is responsible for that session.

About your point about logging out:
The client is responsible for the logout behavior. If a user clicks on a logout button example it could choose to end its own session or end both its own and the IdentityServer session. In ASP.NET Core terms the latter would mean signing out from both the cookie and oidc scheme. Note that the client isn't able to remove a cookie set by the identity provider, so it has to redirect to it when logout occurs.

Does this clear things up for you?