Identityserver4: Storing client_secret in appsettings.json without SHA256?

[improwise]

We have put client configuration in appsettings.json and load it using:

.AddInMemoryClients(configuration.GetSection("IdentityServer:Clients"));

which works fine. However, that only works if you SHA256 encode the client secret first, which is a bit of a hassle.

Is there a way to store it plain text in appsettings but instead do the encoding in code using HashExtensions (or something similar)? Since we are calling AddInMemoryClients directly with the configuration, we don't really have a way to do this, unless with do it directly to the IConfiguration object before calling AddInMemoryClients.

Ie, what we would want is to put this:

"ClientSecrets": [ { "Value": "secret" } ],

instead of this:

"ClientSecrets": [ { "Value": "K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=" } ],

in appsettings.

Thanks.

[leastprivilege]

That's exactly what we tried to avoid ;) This is encouraging you to put client secrets in clear text in config files...

[improwise]

Ah, of course, for some reason I got into my head that SHA256 is reversible but of course it isn't. Shame on me :)

[improwise]

Sorry, two additional questions here:

1. What would actually be the drawback of storing the passwords in plain text as if someone could access the appsettings file, the would most likely be able to change the secret (client config) anyway and thus could authenticate against the Identity Server and get a token?

2. Are there some recommended best practices regarding this when mainly using the Identity Server to authenticate a few APIs rather than normal users and using in-memory configuration? Most samples I have seen seem to put client config in code but I assume that isn't really something you would use in a normal production scenario.

Thanks.

[leastprivilege]

1) being able to read (or any leakage of data) and being able to modify are two completely different attacks
2) storing secrets is hard...many options here. maybe inject them on the server as environment variables..

[improwise]

Yes, I agree, this is always a bit tricky. Thanks.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.