Client application (oidc) is redirected to login when IdentityServer4 is restarted

Question

I have an implementation of IdentityServer with an external Provider to authenticate and a client application that implements oidc implicit flow with the oidc-client library. All works correctly (login, logout, refresh token, ecc…) until the IdentityServer shut down (for example due to inactivity).

When the IdentityServer is restarted my client is redirected to login also if the session/token is still valid. I tried with either OperationalStore or InMemoryPersistedGrants but, after the restart of the service and without closing the browser, I have always the same behavior. It’s like if any session/token is stored on database with the OperationalStore enabled. The cookie instead is correctly persisted by browser session and permit to navigate through the IdentityServer pages after the restart without asking for login.

The API call (from client) that redirect to login, after the service restart, is this one: IdS-server/connect/authorize?client_id=client-id&redirect_uri=redirectUri&response_type=code&scope=scopes&state=state&code_challenge=codeChallenge &code_challenge_method=S256&response_mode=query

Is there some missing or wrong configuration in my IdentityServer?

        //
        // IdentityServerBuilder
        //
        identityServerBuilder = services.AddIdentityServer();

        // this adds the operational data from DB (codes, tokens, consents)
        identityServerBuilder.AddOperationalStore(options =>
        {
            options.ConfigureDbContext = builder =>
                builder.UseSqlServer(connectionString,
                    sql => sql.MigrationsAssembly(migrationsAssembly));

            // this enables automatic token cleanup. this is optional.
            options.EnableTokenCleanup = true;
            options.TokenCleanupInterval = 30;
        });


        identityServerBuilder.AddInMemoryIdentityResources(identityServerService.GetIdentityResources())
            .AddInMemoryApiScopes(identityServerService.GetApiScopes())
            .AddInMemoryApiResources(identityServerService.GetApiResources())
            .AddInMemoryClients(identityServerService.GetClients());


        identityServerBuilder.AddTestUsers(identityServerService.GetUsers().ToTestUsers().ToList());

        identityServerBuilder.AddDeveloperSigningCredential();

        //
        // AuthenticationBuilder
        //
        var cookieScheme = identityServerConfig.GetCookieSchemeOrDefault();

        if (identityServerConfig.IsCookieSchemeCustom())
        {
            authenticationBuilder = services.AddAuthentication(cookieScheme).AddCookie(cookieScheme, options =>
            {
                options.Cookie.SameSite = Microsoft.AspNetCore.Http.SameSiteMode.None;
                options.Cookie.SecurePolicy = Microsoft.AspNetCore.Http.CookieSecurePolicy.Always;
            });
        }
        else
        {
            authenticationBuilder = services.AddAuthentication().AddCookie(options =>
            {
                options.Cookie.SameSite = Microsoft.AspNetCore.Http.SameSiteMode.None;
                options.Cookie.SecurePolicy = Microsoft.AspNetCore.Http.CookieSecurePolicy.Always;
            });
        }

Answer 1

Because you use this statement in production:

AddDeveloperSigningCredential()

This means that the token signing key will be recreated if you don't remember it across development. A best practice it to not use this statement in production and instead add a more permanent signing key, perhaps in a database, or in Azure Key Vault or somewhere else where it can be stored safely.

A second thing is that you also need to configure is the Data Protection API and pass it an encryption key that is also persisted outside your system. This is a similar thing to the signing key issue. I did a blog post about it here. The encryption key must be the same across deployment, otherwise the users will be signed out after redeployment because their cookies will no longer be accepted.