OpenID Connect中的公钥

Question

我目前正在尝试使用IdentityServer4为我的用户在不同的应用程序中构建单点登录体验。它们都托管在同一本地网络中，并且没有第三方应用程序通过它进行身份验证。客户端应用程序仍然是基于Katana / Owin的。

我正在使用隐式工作流程。

目前我仍然使用在运行时随机生成的证书来签署令牌。

我想知道

• 我是否真的需要更多，以及留下它的含义是什么和
• 客户实际验证签名的方式。

对于第二个问题，我在openidconnect规范中找到了这篇文章：

  

OP通过其Discovery文档公布其公钥，或者可以   通过其他方式提供此信息。 RP宣布公开   密钥通过其动态注册请求，或可以传达此信息   通过其他方式获取信息。

这是否意味着Katana实际上是从IdentityServer4获取公钥并相应验证？如果是这样，如果证书发生变化会有关系吗？发出和验证令牌之间的时间总是非常小，对吗？那么为什么我需要一个适当的，很少变化的证书？

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.