Redirecting back to client application after logging out from the external identity provider

[okhara]

Identity server version 6.2.3
.NET version 6.0

Redirecting back to client application after logging out from the external identity provider

User is not redirected back to the client application from external identity provider, when identity server is configured for asp.net identity.
For example, if we use one of the quickstart projects from duende samples and add oidc identity provider (we can use one of the clients from https://demo.duendesoftware.com/) we will be able to login through the identity provider successfully, but when we try to logout, process will go through logout to the identity provider and will not redirect back to the identity server and to the client application.

To Reproduce

1. Configure web application as client and identity server for asp.net identity (.AddAspNetIdentity<ApplicationUser>()).
2. Add oidc identity provider (.AddInMemoryOidcProviders).
3. Log into the client application through identity server using external identity provider configured in the second step.
4. Log out from the client application.

Expected behavior

User is logged out from client application, identity server and external identity provider, after which user is redirected back to client application.

Actual behavior

User is not redirected back to the client application.

Solution

Link to PR
After some debugging of the duende and Microsoft sources, I've discovered that the reason for the redirection problem is the absence of id token. SignOutScheme which is used to retrieve id token from the user is set to default value, but default authentication scheme after configuring identity server for asp.net identity is changed to Identity.Application.

[josephdecock]

Thanks for opening this issue. We'll take a look soon!

[brockallen]

This should work from our quickstart samples. Have you tested those? Or have you finally sorted out the issue?

[okhara]

I have tested it out. The quickstart project which is configured with asp.net identity doesn't work as expected.

Link to the specific quickstart

When I use quickstart linked above, and configure dynamic providers for it (for example using duende's demo identity server as dynamic provider) user is not redirected from external provider back to identity server and back to the client application.

The reason for not being redirected is the absence of id_token_hint from the end session request to the external provider. As the id_toke_hint is absent, external identity provider doesn't redirect to post_logout_redirect_uri. Which is perfectly understandable based on OpenID Connect specs.

The reason of absent id_token_hint is configuring duende with asp.net identity, i.e. calling .AddAspNetIdentity() extension method.

When configuring asp.net identity Microsoft.AspNetCore.Authentication.AuthenticationOptions.DefaultAuthenticateScheme is set to Identity.Application. But the Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectOptions.SignOutScheme is set to Duende.IdentityServer.Configuration.IdentityServerOptions.DynamicProviders.SignOutScheme (Link to the OidcConfigureOptions) value of which is idsrv. Which causes the authentication and logout process to use different schemes (Identity.Application and idsrv).

Solution provided by me suggests one of the method for fixing this issue, with setting SignOutScheme of DynamicProviderOptions to the Microsoft.AspNetCore.Authentication.AuthenticationOptions.DefaultAuthenticateScheme.

[josephdecock]

Thanks again for this bug report @ivan-sedlak-visma. I've now managed to reproduce this problem and we're reviewing your PR. In the short term, I believe you can work around this issue with configuration like this:

        builder.Services
            .AddIdentityServer(options =>
            {
                options.DynamicProviders.SignOutScheme = IdentityConstants.ApplicationScheme;

                // rest omitted...
            });

But we do agree that it would be better if the two features understood each other and no manual configuration was necessary.

[josephdecock]

This was resolved in #1265