I use IdentityServer to manage access to a few client APIs with the configuration details stored in SQL. The one downside to using IdentityServer is that there doesn’t yet seem to be a good option for administration of credentials, though Skoruba.IdentityServer4.Admin certainly looks promising.

In order to add new clients I therefore just insert into the underlying SQL tables, this is all pretty obvious apart from for the secrets tables (ApiSecrets, ClientSecrets) which take a hash of the secret, not the secret itself.

The value to be inserted is the SHA256 hash of your secret but this hash also needs to be Base64 encoded. This can be generated with the following SQL code from this stackoverflow answer.

DECLARE @HASHBYTES VARBINARY(128) = hashbytes('sha2_256', N'secret')
SELECT cast(N'' as xml).value('xs:base64Binary(sql:variable("@HASHBYTES"))', 'varchar(128)');

One thing to note is that there appears to be an issue with some special characters which when present in the secret prevent authentication. Unfortunately I’m not sure which specific ones or where exactly in the process they’re causing the issue.


3 Comments

Tom Tuttle · 18th July 2019 at 4:27 pm

Thank you! I’m playing with IS4 and Skoruba and getting it going with EF but have a chicken & the egg situation.

Michael · 28th November 2019 at 11:11 am

Perhaps if you put a N in front of the secret then the special character is processed? like so

DECLARE @HASHBYTES VARBINARY(128) = hashbytes(‘sha2_256′, N’secret’)

    Shinigami · 29th November 2019 at 10:54 am

    Ah yes, that’ll probably do it. Thanks 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *