The Authorization Server will sign tokens with a key. Resource Server(s) should verify that the token’s integrity with a key. Together they form a (usually asymmetric, e.g. public/private) key (pair). By default IdentityServer will publish the public key for verifying tokens via the /.well-known/openid-configuration
endpoint.
For development scenarios, you typically want to skip the fuss of properly managing secrets like said keys (which is really important to do properly in production!). For these development scenarios you have the option of using adhoc solutions like AddTemporarySigningCredential
, which was used for .NET Core 1.x.
With .NET Core 2.x this will change and you will need the AddDeveloperSigningCredential()
extension method.
That answers the question of what it is. On how to use it: you simply call the method you need depending on your .NET Core version inside the ConfigureServices(...)
method of your application’s Startup
class.
Apart from that you don’t need to do anything special, except of course take care that you use a proper key pair in production.
See also the docs on Cryptography, Keys and HTTPS and the bit on Configuring Services for Keys. From the latter document, here’s a relevant alternative for production cases:
AddSigningCredential
Adds a signing key service that provides the specified key material to the various token creation/validation services. You can pass in either an
X509Certificate2
, aSigningCredential
or a reference to a certificate from the certificate store.