Public keys in OpenID Connect

Question

I'm currently trying to use IdentityServer4 to build a single-signon experience for my users across different apps I have. They are all hosted in the same local network and no third-party apps authenticate with it. The client apps are still Katana/Owin-based.

I'm using the implicit workflow.

At the moment I still use a certificate randomly generated at runtime to sign tokens.

I wonder

• whether I actually need more and what the implications are of leaving it as it is and
• how the signature is actually validated by clients.

To the second question I found this piece in the openidconnect spec:

The OP advertises its public keys via its Discovery document, or may supply this information by other means. The RP declares its public keys via its Dynamic Registration request, or may communicate this information by other means.

So does that mean Katana is actually getting the public keys from IdentityServer4 and validates accordingly? And if so, would it matter if it the certificate changes? The time between issuing and validating a token is always very small, correct? So why would I need a proper, rarely-changing certificate?

Answer 1

Generating a new certificate on app startup has a few downsides:

• If you restart your IDS4 process you effectively invalidate any otherwise valid tokens as the signature will no longer be valid
• Inability to scale out - all servers need to have the same signing and validation keys
• Clients might only periodically update their discovery info so you need to allow for a rollover period, something that IDS4 supports as you can have more than one validation key.

See the guidance here: http://docs.identityserver.io/en/release/topics/crypto.html

The next simplest option would be to use a self-issued cert that's installed in the host machine's ceritificate store.

Answer 2

First of all, OpenID Connect discovery is a process of communicating relying party to retrieve provider's information, dynamically. There is a dedicated specification for this, OpenID Connect Discovery 1.0

According to it's metadata section, jwks_uri explains about token signing key publication.

1. So does that mean Katana is actually getting the public keys from IdentityServer4 and validates accordingly?

Yes it should. If your applications (relying parties) want dynamic information, you should go ahead with discovery document to retrieve token signing key information.

2 And if so, would it matter if it the certificate changes? The time between issuing and validating a token is always very small, correct?

Discovery document is part of OpenID Connect dynamic (reference - http://openid.net/connect/ ). So yes, it can be used to convey certificate changes to relying party (token consumers)

3. So why would I need a proper, rarely-changing certificate?

Certificate must be there to validate id tokens issued by identity provider. So at minimum, certificate must live till last token expires. Other than that, one might be using proper certificates issued by a CA, which comes with a cost. So, some implementations could have rarely changing certificates.

Bonus : how the signature is actually validated by clients.

You hash your received message, compare it against decrypted signature using public key of the certificate. Also, if you are wondering the format of key information, it is a JWK defined by RFC7517.

P.S - ID Token validation is same as validating a JWT explained by JWT spec.

Note - I am not an expert in PKI domain. Some expert could point out something else for short lived certificates independent of OpenID Connect protocol.