Frontchannel logout not working as expected

[l3wl3w00]

IdentityServer version

7.0.4

.NET version

8

Description

Hi!

I am working on a POC, that is meant to be a demo about how SSO and BFF can work together using Duende. There are 8 simultaniously running processes in the demo (Most of these components are not relevant to my problem, but for sake of completeness I will list them here):

• The identity server using this template
• 2 BFF servers using Duende BFF Security Framework and using this template
• 2 SPA Angular Clients for the BFF servers. These will be called BFF clients from now on
• A common backend WEB API for both BFF apps (the angular clients send calls to the BFF and the calls are proxied to the backend)
• A normal application not using BFF at all. This app consits of an SPA Angular client and a WEB API. The client for this app will be called non-BFF client from now on

My goal is to implement

• SSO (even between the BFF and non-BFF apps) - so after 1 client logs in, the second one doesn't need to
• Silent Refresh (even between the BFF and non-BFF apps)
• Global logout (even between the BFF and non-BFF apps)

What I implemented so far mostly works fine, however I have an issue with the global logout, specifically with notifying the client of the non-BFF app that a logout happened. For the BFF applications the logout notification is sent using backchannel logout, however I can't do that with an application that doesn't have a BFF component. If I understand correctly from the docs, the way to notify the client in this case is to use frontchannel logout (https://docs.duendesoftware.com/identityserver/v7/ui/logout/notification/). I implemented a page called /signout-oidc in the non-BFF client, that logs the user out upon loading the page:

@Component({
  selector: 'signout-oidc',
  standalone: true,
  imports: [CommonModule],
  template: `
    <p>Signing out...</p>
  `,
  styleUrl: './app.component.css',
})
export class SignoutOidcComponent implements OnInit {
  constructor(private readonly oauthService: OAuthService) {}
  ngOnInit() {
    console.log('Signing out...');
    this.oauthService.logOut(true);
    console.log('Signed out.');
  }
}

I use the angular-oauth2-oidc library.
I have the identity server on port 5000, and the no-BFF client on port 4203.

So this is how it works now:

• Any client (other than the non-BFF app) logs out
• The logged out client gets redirected to the Identity Server's LoggedOut page
• This page contains an iframe embedded within it, with src set to the /signout-oidc of the client
• The html contents of the iframe are correctly loaded

The problem I am having happens in this step: Even though the code angular component is executed (Both "Signing out..." and "Signed out." are logged, no exceptions are thrown), my client is not getting logged out - it does not delete the token locally. Hovewer if I just copy the src of the iframe, and I directly query that page in a new browser tab, it then correctly deletes all tokens, and the logout completes.

I want the non-BFF client to be correctly notified of the logout, so it can invalide it's local storage.

What I suspect the bug is:
The localstorage/sessionstorage is seperate for localhost:5000 and localhost:4203, and even though the iframe uses a source that is on localhost:4203, it still can't access the local storage on that port.

However, if this is the case, then frontchannel logout shouldn't work in general at all, becasue the identity server wouldn't be able to notify, or share any data whatsoever with the other clients this way. That is why I think there is a common way to do this that I can't seem to find or figure out. Is it possible this is a bug?

I would appreciate any help or advice you have regarding this problem.

You can view the full source code here

Reproduction steps

• Use the ./start.ps1 script to start all processes. This will open 3 windows in the browser, the 2 BFF clients and the non-BFF client
• Log in with any of the clients (user: alice, pass: alice)
• Click "log out" on any BFF client (will get redirected)
• Click on the non-BFF client's tab and refresh
• You will still see the token, even though it is supposed to be invalid now

Expected behavior

Upon singing out from any client, the non-BFF client gets notified and correctly deletes all data stored about the token for the current session.

Logs

No response

Additional context

No response

[RolandGuijt]

Browsers get more and more restricted with cross site requests. That's why unfortunately the usability of front-channel logout is decreasing.
I suspect your issue has something to do with that.

Can you please try your scenario with different browsers and see if others work?

[l3wl3w00]

Sorry for not mentioning it, I did try it in several different browsers, and none of them worked, but to be absolutely sure, I tested it again with 4 different browsers: Google Chrome, Microsoft Edge, Opera, Firefox. In none of them did the logout work from the iframe, and in all of them did the logout work when I manually accessed the /signout-oidc page.

I also read that it could be because 3rd party cookies are blocked in the browser, so I set the cookie settings to allow 3rd party cookies where I could, but that didn't fix it.

[RolandGuijt]

In Chrome's devtools when clicking on a request in the network tab there's a cookie tab. Can you enable "Filtered out request cookies" there and see if the cookie is blocked somehow and for what reason?
Also: does this occur when the applications run on their own URL as opposed to all on localhost?

[l3wl3w00]

So I made the angular run on http://no-bff-client.test:4203 (I also modified my 'hosts' file accordingly), this way it is on a different domain from https://localhost:5000 (the identity server). I still have the exact same issue.

I checked the filtered out cookies in every request in the process, I will place a screenshot here for each request and the url of the given request (the yellow cookies are the filtered ones):

Request url: https://bff-server-2.test:5002/bff/logout?sid=8197B1350D6FF94B9A42031C3CDD4405&returnUrl=http://bff-client-2.test:4202

Request url: https://localhost:5000/connect/endsession?post_logout_redirect_uri=https%3A%2F%2Fbff-server-2.test%3A5002%2Fsignout-callback-oidc&id_token_hint=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIzNTE2NUIzQkI1NTA1MjBCNTJBOUZDOTY5RUE3RkNEIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwczovL2xvY2FsaG9zdDo1MDAwIiwibmJmIjoxNzQxMzUyMTAxLCJpYXQiOjE3NDEzNTIxMDEsImV4cCI6MTc0MTM1MjQwMSwiYXVkIjoiYmZmMiIsImFtciI6WyJwd2QiXSwibm9uY2UiOiI2Mzg3Njk0ODg5OTUyMDI2NDguWkRoa05URmxOemt0TUdZMU1TMDBORE0xTFRnME5qa3RObVEwTmpOaE56QTBNMlUxWWpObU16TmhNVEl0WXpjeVpDMDBOMlkwTFdFeFptVXRPV1l3TVRRNE1UUXdPVFUxIiwiYXRfaGFzaCI6Ing1N1ZGbW5QQTJtRFVSaHhPQy15WUEiLCJzaWQiOiI4MTk3QjEzNTBENkZGOTRCOUE0MjAzMUMzQ0RENDQwNSIsInN1YiI6IjIiLCJhdXRoX3RpbWUiOjE3NDEzNTIxMDEsImlkcCI6ImxvY2FsIiwibmFtZSI6IkJvYiBTbWl0aCIsImdpdmVuX25hbWUiOiJCb2IiLCJmYW1pbHlfbmFtZSI6IlNtaXRoIiwiZW1haWwiOiJCb2JTbWl0aEBlbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwid2Vic2l0ZSI6Imh0dHA6Ly9ib2IuY29tIiwiYWRkcmVzcyI6eyJzdHJlZXRfYWRkcmVzcyI6Ik9uZSBIYWNrZXIgV2F5IiwibG9jYWxpdHkiOiJIZWlkZWxiZXJnIiwicG9zdGFsX2NvZGUiOiI2OTExOCIsImNvdW50cnkiOiJHZXJtYW55In19.sgL94ApPk43GpQkQTRKIy_v_SULR2AHtH6tY2xQ58M4dEdXwSnHgHxk2H06LTBBFtg_3hmHfO8oXu-2iywnPZx3UMWAXiHXgSikTQAoMEcLeeDVw4mOIodHe29gBGqsTBbLHIc3DWrtGzds9ZbdMdS_GbUHLkbT6_cxdz_x6aPt3T9EcAHuKe6SYj_8OznaCmI-LnDcLOh9RuPhEpIJoFDGrjvYAns6klLdVkwPj1V-vrnWJrRZC0qruza97NuyxAhmqWJVL0bIaM4Ekml4xeL4I2XAtkuiLs84uP5S66wm2wkbvcQwG2JFP_um0sX1Esg5Q2b2sKfZBMi1xcT3L8g&state=CfDJ8Ekv4mgMRfJOnK42zYgWmSFI4Qb53YDc3JhMkshmux1h7HQQSSMq4wfU8StoyeXQ4C8LA07chnyYSsCuGlu36lPQBYzGbd2NrAEM9J2drL_awhrfxo_-9RhDlATaq1V4orEa6qbu0N8rQnlCanF3UopHHJbhXbp0_vDLtZ7NndbPQ-LGp2eHWIMQtgWHyGLVNA&x-client-SKU=ID_NET8_0&x-client-ver=7.0.3.0

Request url: https://localhost:5000/Account/Logout?logoutId=CfDJ8Ekv4mgMRfJOnK42zYgWmSGXfEa5N3nfk-uw_OwkFQWUhSdsCpMi6OifZJe9568V3dt7WqLxge-yDh7igNnqDwZAPaIYCl8IgFDYDXMdbb407Mow4ly5hMoQLkh8TfFlUILN7HvugP9y8dkrp321WjOwDJEni7JFHxuhtwppbxH0vmVzh39VySBWn5b06teer9UNQ_P4SJ5pHjzb2DaMZreU9SD8RD49fAlWS_vroHjH9U0bBBNm2dBGdIJcExEKlr0nYyx5zxQKUB05D19l9ibHM6VG6KHpM6nE5G3X545yowsvPcNsia3CMkOfSuUynzZAiPbg5QXI_0MKsKgzMLqkhXWst6EfutC0leLuBuSClFC9WleAtWqk59BWRQ8BkKWte_0G0mnxu4eXlo5IVZ_y3j1wwXZMXtH4QuNsW7G66zxnyhljCNUOkpJssRSrRAV3A8uWwoeOnrdoEiiiWkg

Request url: https://localhost:5000/Account/Logout/LoggedOut?logoutId=CfDJ8Ekv4mgMRfJOnK42zYgWmSGXfEa5N3nfk-uw_OwkFQWUhSdsCpMi6OifZJe9568V3dt7WqLxge-yDh7igNnqDwZAPaIYCl8IgFDYDXMdbb407Mow4ly5hMoQLkh8TfFlUILN7HvugP9y8dkrp321WjOwDJEni7JFHxuhtwppbxH0vmVzh39VySBWn5b06teer9UNQ_P4SJ5pHjzb2DaMZreU9SD8RD49fAlWS_vroHjH9U0bBBNm2dBGdIJcExEKlr0nYyx5zxQKUB05D19l9ibHM6VG6KHpM6nE5G3X545yowsvPcNsia3CMkOfSuUynzZAiPbg5QXI_0MKsKgzMLqkhXWst6EfutC0leLuBuSClFC9WleAtWqk59BWRQ8BkKWte_0G0mnxu4eXlo5IVZ_y3j1wwXZMXtH4QuNsW7G66zxnyhljCNUOkpJssRSrRAV3A8uWwoeOnrdoEiiiWkg

Request url: https://localhost:5000/connect/endsession?post_logout_redirect_uri=https%3A%2F%2Fbff-server-2.test%3A5002%2Fsignout-callback-oidc&id_token_hint=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIzNTE2NUIzQkI1NTA1MjBCNTJBOUZDOTY5RUE3RkNEIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwczovL2xvY2FsaG9zdDo1MDAwIiwibmJmIjoxNzQxMzUyMTAxLCJpYXQiOjE3NDEzNTIxMDEsImV4cCI6MTc0MTM1MjQwMSwiYXVkIjoiYmZmMiIsImFtciI6WyJwd2QiXSwibm9uY2UiOiI2Mzg3Njk0ODg5OTUyMDI2NDguWkRoa05URmxOemt0TUdZMU1TMDBORE0xTFRnME5qa3RObVEwTmpOaE56QTBNMlUxWWpObU16TmhNVEl0WXpjeVpDMDBOMlkwTFdFeFptVXRPV1l3TVRRNE1UUXdPVFUxIiwiYXRfaGFzaCI6Ing1N1ZGbW5QQTJtRFVSaHhPQy15WUEiLCJzaWQiOiI4MTk3QjEzNTBENkZGOTRCOUE0MjAzMUMzQ0RENDQwNSIsInN1YiI6IjIiLCJhdXRoX3RpbWUiOjE3NDEzNTIxMDEsImlkcCI6ImxvY2FsIiwibmFtZSI6IkJvYiBTbWl0aCIsImdpdmVuX25hbWUiOiJCb2IiLCJmYW1pbHlfbmFtZSI6IlNtaXRoIiwiZW1haWwiOiJCb2JTbWl0aEBlbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwid2Vic2l0ZSI6Imh0dHA6Ly9ib2IuY29tIiwiYWRkcmVzcyI6eyJzdHJlZXRfYWRkcmVzcyI6Ik9uZSBIYWNrZXIgV2F5IiwibG9jYWxpdHkiOiJIZWlkZWxiZXJnIiwicG9zdGFsX2NvZGUiOiI2OTExOCIsImNvdW50cnkiOiJHZXJtYW55In19.sgL94ApPk43GpQkQTRKIy_v_SULR2AHtH6tY2xQ58M4dEdXwSnHgHxk2H06LTBBFtg_3hmHfO8oXu-2iywnPZx3UMWAXiHXgSikTQAoMEcLeeDVw4mOIodHe29gBGqsTBbLHIc3DWrtGzds9ZbdMdS_GbUHLkbT6_cxdz_x6aPt3T9EcAHuKe6SYj_8OznaCmI-LnDcLOh9RuPhEpIJoFDGrjvYAns6klLdVkwPj1V-vrnWJrRZC0qruza97NuyxAhmqWJVL0bIaM4Ekml4xeL4I2XAtkuiLs84uP5S66wm2wkbvcQwG2JFP_um0sX1Esg5Q2b2sKfZBMi1xcT3L8g&state=CfDJ8Ekv4mgMRfJOnK42zYgWmSFI4Qb53YDc3JhMkshmux1h7HQQSSMq4wfU8StoyeXQ4C8LA07chnyYSsCuGlu36lPQBYzGbd2NrAEM9J2drL_awhrfxo_-9RhDlATaq1V4orEa6qbu0N8rQnlCanF3UopHHJbhXbp0_vDLtZ7NndbPQ-LGp2eHWIMQtgWHyGLVNA&x-client-SKU=ID_NET8_0&x-client-ver=7.0.3.0

And this last request has no cookies

[RolandGuijt]

Thanks for all the details. Looking at them this probably still is a issue with the browser not allowing access to local storage with a cross-site request. The only solution would be, also in the long run because browsers are getting more and more restricted, to either run the Angular application same-site or switch to the BFF pattern and use backchannel logout.
Sorry I can't be more helpful.

[l3wl3w00]

Thank you for your answers! Unfortunately the whole point of this part of the demo is to demonstrate that a BFF and a non-BFF application can work together with SSO, which I am now doubting is possible. :(

Do you think maybe something like this could work?

• The backend of the non-BFF application has a backchannel logout endpoint
• Upon logout the identity server calls it, just like with all the other backchannel endpoints
• The backend somehow notifies the angular client that a logout happened
• The client invalidates its local session

This kind of feels like it's a hacky solution, is this common practice?

Also, if front-channel logout doesn't work in general, and what I described above is not common practice, then doesn't this imply that any application that supports SSO also has to implement BFF in order for global logout to work?

[AndersAbel]

Front-channel logout works in a same-site scenario¹². For single page applications it is even better to use the check session endpoint in a hidden iframe to detect logout.

For cross-site scenarios there is no longer any way to implement front-channel logout reliably because of browser privacy features. Especially Safari will block access to cookies and local storage for an iframe that accesses cross-site content.

Our recommendation is migrate to the backend for frontend pattern for all single page applications as that has a better security model. But for same-site deployments it is still possible to use a JS-based OAuth2/OIDC client and rely on the check session iframe or front-channel logout. Server side applications can only expect front-channel logout to be reliable in same-site scenarios.

Footnotes

1. If users are running Safari there might be additional concerns if the hosting environment uses IP numbers for different ranges. https://www.youtube.com/watch?v=xnU_gp86XFo ↩

2. At least for now, but there is no guarantee that browsers will not change their behaviour in the future. ↩

[SaifAqqad]

is it possible to implement a workaround for the browser restrictions using Storage Access APIs?

Something like authts/oidc-client-ts#1735 where you have a separate iframe whose sole purpose is to display a button to prompt the end user to allow access to the full storage of the idp inside the iframe, after the user accepts, the normal check_session iframe is started and should work as it usually does.

I'm not 100% sure, but I think this would require a change in the check_session iframe js code where it should first check if it has storage access and should wait for a message from the RP frame to notify it that permission has been granted by the other frame so it can start.

Would appreciate any feedback on this, as I would prefer this route over having to implement back-channel notifications

[RolandGuijt]

In our experience more and more browsers prevent a solution like this for the same reasons cross site cookies are blocked.

[sccunningham7]

Not to hijack a potentially different issue, I have also run into a problem with front channel logout, but with a BFF client on the same site as the Identity Server. I have confirmed the cookies are being received and processed.

Since BFF needs DefaultSignOutScheme to be the OIDC scheme, the remote sign out call from the Identity Server doesn't clear the local application cookie. As far as I can tell, the BFF logout endpoint doesn't work properly if DefaultSignOutScheme isn't set to the OIDC scheme. The documentation also implies this.

I built a workaround by using the OpenIdConnectEvents.OnRemoteSignOut event, inspired by how the default OIDC handler is doing this:

options.Events.OnRemoteSignOut = async context =>
            {
                // If the message is null, return. Let the next OIDC handler take care of it. It will also take care of logging for us.
                if (context.ProtocolMessage == null)
                {
                    return;
                }

                // Verify the request is authenticated, otherwise we don't need to do anything
                var authenticateResult = await context.HttpContext.AuthenticateAsync();
                if (authenticateResult.Succeeded)
                {
                    // Try to extract the session identifier from the authentication ticket persisted by the sign-in handler.
                    // If the identifier cannot be found, bypass the session identifier checks: this may indicate that the
                    // authentication cookie was already cleared, that the session identifier was lost because of a lossy
                    // external/application cookie conversion or that the identity provider doesn't support sessions.
                    var contextSid = context.ProtocolMessage?.Sid;
                    var authTicketSid = authenticateResult.Principal.FindFirstValue(JwtRegisteredClaimNames.Sid);
                    if (!string.IsNullOrEmpty(authTicketSid))
                    {
                        // Ensure a 'sid' parameter was sent by the identity provider.
                        if (string.IsNullOrEmpty(contextSid))
                        {
                            return;
                        }

                        // Ensure the 'sid' parameter corresponds to the 'sid' stored in the authentication ticket.
                        if (!string.Equals(authTicketSid, contextSid, StringComparison.Ordinal))
                        {
                            return;
                        }
                    }

                    var contextIss = context.ProtocolMessage?.Iss;
                    var authTicketIss = authenticateResult.Principal.FindFirstValue(JwtRegisteredClaimNames.Iss);
                    if (!string.IsNullOrEmpty(authTicketIss))
                    {
                        // Ensure a 'iss' parameter was sent by the identity provider.
                        if (string.IsNullOrEmpty(contextIss))
                        {
                            return;
                        }

                        // Ensure the 'iss' parameter corresponds to the 'iss' stored in the authentication ticket.
                        if (!string.Equals(authTicketIss, contextIss, StringComparison.Ordinal))
                        {
                            return;
                        }
                    }

                    // End the local app cookie session. After this, the default OIDC handler will take care of the OIDC signout.
                    await context.HttpContext.SignOutAsync(CookieConstants.AuthenticationScheme);
            };

I'd love to know if there is a proper way to get this to work. I don't think this is a bug in BFF necessarily. The logic of why this happens makes sense. But it certainly doesn't seem like intentional behavior.

[AndersAbel]

This shouldn't be needed, so I guess there's a config issue somewhere. Would you mind sharing the options in AddOpenIdConnect? (remember to redact, Authority, ClientId, ClientSecret and any sensitive scope names etc.)

[sccunningham7]

builder.Services.AddBff();
builder.Services.AddAuthentication(options =>
            {
                options.DefaultScheme = "cookies";
                options.DefaultChallengeScheme = "oidc";
                options.DefaultSignOutScheme = "oidc";
            })
            .AddCookie("cookies",
                options =>
                {
                    options.Cookie.SameSite = SameSiteMode.None; // For testing with localhost
                    options.Cookie.HttpOnly = true;
                    options.Cookie.IsEssential = true;
                    options.ExpireTimeSpan = TimeSpan.FromHours(5);
                    // Events which prevent redirect and instead return 401 or 403, omitted for brevity
                })
            .AddOpenIdConnect("oidc",
                options =>
                {
                    options.Authority  = "";
                    options.ClientId = "";
                    options.ClientSecret = "";
                    options.ResponseType = OpenIdConnectResponseType.Code;
                    options.ResponseMode = OpenIdConnectResponseMode.Query;
                    options.SaveTokens = true;
                    options.TokenValidationParameters.NameClaimType = JwtClaimTypes.Subject;
                    options.TokenValidationParameters.RoleClaimType = JwtClaimTypes.Role;

                    options.MapInboundClaims = false;
                    options.Scope.Clear();
                    options.Scope.Add(OpenIdConnectScope.OpenId);
                    options.Scope.Add(OpenIdConnectScope.Profile);
                    // Various other scopes and claim mappings here, omitted for brevity
                });

The identity server is calling the remote sign out from the iframe, which results in the client application calling the endsession endpoint on the identity server, because the default sign out scheme is the OIDC scheme. The client application cookie from the "cookie" scheme is not cleared.

In non-BFF apps on the same site, everything works here as expected.

[RolandGuijt]

The code looks like it should work. To investigate what's going on can you please provide us with the requests that are going on? You can see them on the network tab using the F12 tools of the browser. Please preserve the log (should be a checkbox) during the process.

[sccunningham7]

Bear with me, lots to redact. This is the result when signing out from the non-BFF MVC app:

iframe 1 is the non-BFF MVC app.
iframe 2 is the BFF app.

This does not end up removing the application cookie for the BFF app. Notably, this might be because signout-oidc is causing a 302 in the BFF app which ends up not triggering the cookie signout.

[RolandGuijt]

Do you have priority support? (Comes with an Enterprise license e.g.). If so please contact us there. We might be able to help you out better there.

[sccunningham7]

We do, and can contact you there.