Validating against Identity server 4 EF in cloudscribe - secret fails

[JamesPe]

I have a test project setup using the cloudscribe template and selecting the IdentityServer option. This all worked well.

I am trying to protect an API on the site for use by only allowed clients.

I have created an API and a client using the cloudscribe Administration /Security Settings /API Resources or API clients menu options.

I can see the items in the db (csids_Clients and csids_ApiResources)

I am trying to connect from a different application as described below (which works fine for In Memory clients / apis as described here - [https://identityserver4.readthedocs.io/en/release/quickstarts/1_client_credentials.html#creating-the-client]

However when I try and connect to the db storage it fails - I can see in the cs_SystemLog table that the clienty is correct - and accepted but I get an error every time:

IdentityServer4.Validation.ClientSecretValidator - Client secret validation failed for client: client2.

As you can see I've been trying with both sha256 and without.

Looking in the csids_ClientSecrets table - I can see my secret value there in plain text.

Assuming the error log is telling the truth - am I tripping over some sort of character encoding issue ?

I can avoid the issue by setting the client to not require a secret - in which case I get a token returned successfully

Any ideas appreciated
Thanks

            // discover endpoints from metadata
            var disco = await DiscoveryClient.GetAsync("http://localhost:9931");

            // request token
            var tc = new TokenClient(disco.TokenEndpoint, "client2", "secret3");
            var tr = await tc.RequestClientCredentialsAsync("api2");

            //Try with toSha56
            var tokenClient = new TokenClient(disco.TokenEndpoint, "client2", "secret3".ToSha256());
            var tokenResponse = await tokenClient.RequestClientCredentialsAsync("api2");

[joeaudette]

@JamesPe off the top of my head I don't know the answer. IdentityServer4 is a very complex configurable thing, and I don't really consider myself an expert at it yet.

Would it be possible for you to fork this repository and add a minimal client into the existing sample solution with the configuration as you are trying to do to demonstrate the problem?

This sample uses nodb so it would mean I would be able to clone your fork and try it as you have it setup with actual data and see the problem and then try to solve it.

If you can do that and then post the link to your fork that would be great.

[JamesPe]

Joe - I'll look at doing that when I get a moment - but in the meantime I think I may have found the issue.
The secret needs to be .ToSHA256 encoded when its saved to the database and I don't think your Security page is doing this. The secretType also has to be set to SharedSecret for it to work.

I've tested this by adding a secret in through your page and seeing the client fail to authenticate and then editing the field in the db to add in the SHA256 version of the secret and then the client validates.

As a slight aside / follow up - I think your security pages for Identity Server 4 would be easier for novices like me to get to grips with if some of the fields had drop down lists (e.g. secret type and possibly allowed grant types)

I'll try and write up my experiences such as they are in a blog post - but hope this helps in the mean time

[joeaudette]

I don't think my security page is supposed to do that, I could be wrong, most of that was copied from their own ui example, I only modified it for multi tenancy. I will review theirs again when I get a chance
yes the ui could be nicer but not a top priority for me

[JamesPe]

If you look at their in memory tests they use SHA256 to encode a secret when they create the client (which is what gave me the idea of testing it seeing as the secret was showing in the db table as plain text).

My understanding is that you need it when creating the client in the db - but you don't need it when passing the secret in when creating a TokenClient - and I think that matches what my empirical tests have shown.

I understand the UI isn't a high priority and probably doesn't really need to be - my comments were more about the fact that this was an area I struggled with not knowing what the text options were to put in. e.g. for secret type I ended up examining the IdentityServerConstants.SecretTypes constants to find them. Maybe its just my lack of understanding or I have missed some doc somewhere.

I'll try and write up a worked example - at least including the settings I have used to get a result in case it helps others

[JamesPe]

OK - here is a first stab at documenting what I did to get things working. Will have a go at tidying it up when I get the code plugin but wanted to get it down while I remembered. Happy to move to more appropriate location if there is one - https://www.esdm.co.uk/using-cloudscribe-with-identity-server-4-with-sql-server-store-on-dotnet-core-2-mvc-securing-apis

[joeaudette]

Great post! As mentioned in my comments on your post, thanks to your feedback, we have shipped updated nugets of the identityserver integration bits, adding a dropdown for the secret type and a dropdown to choose if you want the value to be hashed on the way into storage.