Bump the jwt-verifier group in /prime-router with 2 updates

[dependabot]

Bumps the jwt-verifier group in /prime-router with 2 updates: com.okta.jwt:okta-jwt-verifier and com.okta.jwt:okta-jwt-verifier-impl.

Updates com.okta.jwt:okta-jwt-verifier from 0.5.7 to 0.5.8

Updates com.okta.jwt:okta-jwt-verifier-impl from 0.5.7 to 0.5.8

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Manifest Files

[github-actions]

Test Results

1 092 tests  ±0   1 054 ✅  - 34   5m 44s ⏱️ -2s
  131 suites ±0       4 💤 ± 0 
  131 files   ±0      34 ❌ +34 

For more details on these failures, see this check.

Results for commit fee5c92. ± Comparison against base commit 3c03a1a.

♻️ This comment has been updated with latest results.

[github-actions]

Integration Test Results

0 files   -  52  0 suites   - 52   0s ⏱️ - 12m 57s
0 tests  - 358  0 ✅  - 348  0 💤  - 10  0 ❌ ±0 
0 runs   - 361  0 ✅  - 351  0 💤  - 10  0 ❌ ±0 

Results for commit fee5c92. ± Comparison against base commit 3c03a1a.

♻️ This comment has been updated with latest results.

[thetaurean]

There is a feature branch with most of the issues in merging this resolved platform/thetaurean/13329-fix-jwt. There is an issue that remains that may prompt changes in our key storage patterns.

The Problem

We use a method parseUnsecuredClaims to deserialize and parse the payload of the token prior to verifying the signature. This required a workaround: truncating the signature for the token or the library would complain. In the latest version the workaround is no longer enough because the alg value is set and the library complains that the token is signed.

Compounding the problem

The library provides a KeyLocator that can be provided to the parser to locate the key. But this pattern only provides the headers -- no built-in access to the payload. This is problematic because we use the issuer claim (in the payload) to determine which organization to pull keys for. More problematic still is there could be multiple keys we have to try.

Current Conclusion

We are going to wait until the jjwt library gets closer to a 1.0.

More Info

Security Concern

The general consensus is that we should not be unpacking the payload before verifying the signature if possible.

Possible solutions

Force the library

Remove the alg value from the header for the initial parse so the library doesn't complain.

Move existing logic inside KeyLocator

Move the existing logic flow of peeking the payload and trying keys into a KeyLocator.

Unique KIDs

Make the kid value unique across orgs -- then we can use this value in the header to find the key. We then just have to make sure the kid belongs to the appropriate org.

Custom Header

We can add our own new header to the JWT that represents the organization ID we are authorizing as

Exposed Issuer

There are some IETF discussions around exposing the issuer somehow. Last discussion was in early January and the draft expires 4/25/2024 so low optimism on this coming to fruition.

Related reading:

GitHub Issue - Closed issue on the library with the same problem we are having (needing access to the issuer in the payload)
JWT Best Practices RFC - Describes best practices with JWT (including unpacking payload without signature verification)
IETF Draft Proposal - Draft proposing changes to provide access to issuer
FHIR Auth Best Practices

[snesm]

@dependabot recreate

[snesm]

@dependabot recreate

[snesm]

@dependabot recreate

[snesm]

@dependabot recreate

[snesm]

superseded by #14947

[dependabot]

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml