fix: OAuth2 iss
claim verification in JWT/OIDC authenticators when used with metadata_endpoint
#1660
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue(s)
same as #1658 (but for the release branch, cherry pick from the referenced PR)
Checklist
Description
The verification of the claims is done using an
Expectation
object initially created from thejwt
authenticator configuration. If themetadata_endpoint
is used, a newExpectation
object, based on the above said one, is created. The contents of that new object is a result of merging the properties from the initial object with data received from the OIDC discovery endpoint, where new data is only used in the resulting object if the old one didn't have them set. Unfortunately the implementation of theMerge()
method, responsible for the creation of that new object was not idempotent. It updated the properties of the initial object during the merge. That way the subsequentExpectation
objects had wrong values.This PR changes the implementation of this method and actually all receivers of the
Expectation
struct to always work on a copy of the corresponding objects.Additional Info
Most uses of the function are only called once, where the bug isn't triggered. However, this prevented the JWT issuer with dynamic Issuer URLs from working correctly because only the first issuer would be taken for eternity as described in the linked bug ticket.