chore: bump golang-jwt to v5

[David-Wobrock]

The rationale behind this update is that we see an ever increasing memory usage on our Oathkeeper instances, until they OOM and we start a new one.

From some pprof analysis in our prod environment, seems to indicate that it's in MutatorIDToken.Mutate that the issue lies.
More specifically when signing the token string.

• in MutatorIDToken.Mutate => signed, err := a.r.CredentialsSigner().Sign(r.Context(), jwks, claims)
• in Sign => signed, err := token.SignedString(key.Key)
• in SignedString => return strings.Join([]string{sstr, sig}, "."), nil

In golang-jwt v5, this method does not use strings.Join anymore.
See golang-jwt/jwt#115

I'm entirely sure to understand why string joining could cause this issue, perhaps some reference that Oathkeeper is keeping and therefore leads to this memory leak 🤷
But in any case, we believe it's a good thing to keep dependencies up-to-date and use the latest version.

Let me know what you think :)

Checklist

• I have read the contributing guidelines.
• I have referenced an issue containing the design document if my change
  introduces a new feature.
• I am following the
  contributing code guidelines.
• I have read the security policy.
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security vulnerability, I
  confirm that I got the approval (please contact
  security@ory.sh) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added or changed the documentation.

Further Comments

[aeneasr]

Very nice! I don't think it will solve the mem leak issue but good to see the update.

The mem leak might come from an incorrect cache configuration for the ID token mutator.

[David-Wobrock]

Very nice! I don't think it will solve the mem leak issue but good to see the update.

The mem leak might come from an incorrect cache configuration for the ID token mutator.

You're right, profiling locally I have the same memory usage on master and this branch.

What obviously helps, is to disable the cache 🙄
But generally, I think that making the id_token mutator cache configurable is probably a good move.
Both enable/disable, but also configure the max cost/tokens - like the authn OAuth2 ClientCredentials and introspection handlers.

I'll try to suggest a PR that adds these options.