Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 7.4 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

The authorization server (OP) should always provide a max-age of the JWKs document and the client should strictly adhere to that value. If the OP wants to rotate its keys, it must publish the new keys well before they are used to sign tokens and should only remove their current keys after they are sure that every previously issued token has expired.
The OP must only use the new keys after they are reasonably sure that the RP has reloaded the JWKs document.

If the RP reloads the JWKs document everytime an unknown kid claim is found, a possible DOS is created. It would be trivial for an attacker to create JWT tokens with different kid claims, which would result in a reload of the JWKs document on every request. This issue would also occur when tokens are still in "circulation", signed by keys that are no longer included in the JWKs document.

In my opinion the RP must trust the key rotation behaviour of the OP. The OidcTokenHandler should be updated to cache the JWKs document for the duration the OP suggests. Currently the default cache ttl is always used.

The only valid point I could come up with is that in case the OP is forced to revoke their keys (e.g. private key was leaked), the RP might not know about the OPs new key yet and reject the token. This is a known limitation of JWTs and boils down to the same problem that already issued JWTs can not be revoked.
If these limitations are not acceptable to your security model, OAuth2 and OpenID Connect do not require the use of JWT access tokens and one can just as well use opaque tokens that have to be introspected on every request.

I strongly urge to close this PR and instead focus on caching the JWKs document with the OPs provided cache instructions.

focus on caching the JWKs document with the OPs provided cache instructions

Makes sense thanks for the comment, anyone up for a PR doing so?

Thanks for proposing, I'm closing per @danielburger1337's rationale.

Indeed, my intention was to cover the case where an OIDC provider might rotate or revoke signing keys unexpectedly, which can lead to token verification issues.

That said, I completely understand and agree with the rationale, following the provider’s cache headers is the correct and standards-compliant approach.

I might explore a follow-up PR implementing proper JWKS caching based on those headers, as suggested.

Thanks a lot for the explanations and the constructive discussion