英文:
Google OAauth Public Cert/Key Rotation - Caching Public Certs
问题
我正在为GCP服务帐户生成id_tokens，并在我的服务中针对Google公钥验证它们（并验证有效负载）。公钥在这里：https://www.googleapis.com/oauth2/v3/certs
我假设有2个密钥，因此在密钥轮换期间可以轻松迁移。然而，关于轮换过程或轮换频率，没有任何文档。
我正在使用此库进行验证 - https://github.com/googleapis/google-auth-library-php。此库将密钥存储在缓存中1小时（AccessToken.php）。这是无法更改的。
理论上，您可能能够将旧密钥缓存高达一个小时，而您可能不知道（假设您在两个密钥轮换之前立即进行了缓存）。此库不遵守Google推荐的Cache-Control标头。
问题：将密钥存储一个小时通常安全吗？我假设Google不会同时轮换两个密钥。并且在Google停止使用密钥对并将其轮换之间存在一段时间窗口。关于此事有文档吗？
英文:
I am generating id_tokens for GCP Service Accounts and verifying those against Google public keys (and validating the payload) in my service. Public keys are here: https://www.googleapis.com/oauth2/v3/certs
I assume there are 2 keys so you can easily migrate during key rotation. However, there is no documentation about the rotation process or how often they do it.
I'm using this library to validate - https://github.com/googleapis/google-auth-library-php. This library stores the keys for 1 hour in the cache (AccessToken.php). This cannot be changed.
Theoretically then, you may be able to cache the old keys for up to an hour and wouldn't know it (assuming you cached right before both keys got rotated). This library does not respect Cache-Control header which Google recommends.
Question: is storing keys for an hour typically safe? I assume Google doesn't rotate both keys at the same time. And there is a window of time between when google stops using a key pair and rotates it. Is there documentation on this?
答案1
得分: 1
这看起来对我来说是一个标准的JWT库，您还应该有选择使用其他PHP JWT库来执行相同的操作。该库会下载并缓存包含令牌签名公钥的JSON Web键集（JWKS）。这是安全的，因为这里没有秘密。
当接收到JWT时，会读取JWT标头中的kid字段。如果此字段已经存在于缓存中，就不会进行新的JWKS查找。缓存的公钥用于验证JWT签名。
当授权服务器旋转其令牌签名密钥时，它会向JWKS中添加一个新的公钥，带有一个新的kid。旧条目将保留一段时间，例如一天或两天，以便正在使用的令牌继续进行验证。
当接收到使用新密钥签名的JWT时，JWT库将在JWT标头中找到一个新的kid，因此会进行新的JWKS下载，以获取新的公钥。因此，对于应用程序来说，更新是无缝的。
我的博客文章以一种可视化的方式解释了这一点，展示了OAuth如何将密钥管理从应用程序中外部化，同时考虑到可靠性。
英文:
Looks like a standard JWT library to me and you should also have the option to other PHP JWT libraries to do the same thing. The library downloads and caches a JSON Web Key Set (JWKS) containing token signing public keys. This is safe since there are no secrets here.
When a JWT is received, the kid field from the JWT header is read. If this exists already in the cache, there is no new JWKS lookup. The cached public key is used to verify the JWT signature.
When the authorization server rotates its token signing key, it adds a new public key to the JWKS, with a new kid. The old entries will remain there for a while, eg a day or two, so that in-use tokens continue to validate.
When a JWT signed with the new key is received, the JWT library will find a new kid in the JWT header, so will do a new JWKS download, to get the new public key. Thus, renewal is seamless for applications.
My blog post explains this in a visual way, to show how OAuth externalizes key management from applications, while also accounting for reliability.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论