feat: make id_token mutator cache configurable

[David-Wobrock]

Make the id_token mutator cache configurable:

• can be enabled/disabled
• can set the max_cost

Changes to default configuration:
Previous:

• NumCounters: 10000
• MaxCost: 1 << 25

New:

• NumCounters: maxCost * 10
• MaxCost: 1 << 25
• Cost function: JWT length

Related issue(s)

Follow up of #1171 and #1209 (and #1210 too a bit).

Related docs PR: ory/docs#1820

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

Could probably be subject to a minor version bump, since there's a behaviour change.

[David-Wobrock]

To be discussed if this is really the best strategy for id_token.

I'm less familiar with other use cases of generated id_token and also how ristretto computes the "cost".

For now, this is copied from the AuthN OAuth2 introspection handler.
But perhaps saying that each id_token = 1 cost would cache too many id_tokens.

I'd like @aeneasr's opinion here :)

[David-Wobrock]

In the current state it does not work, but we could at least do

                        NumCounters: 10000,
			BufferItems: 64,
                        MaxCost: cost,

to keep the same behaviour as previously.

[aeneasr]

cost = 1 << 25

as the default is definitely too many now that the cost function is 1

[aeneasr]

Since JWTs can be quite long it may make more sense to calculate the cost based on the string length to have an approximation of storage use

[David-Wobrock]

That could make sense indeed 👍
Then the default limit of 1 << 25 (~33.5 million), if we estimate an average length of JWT of a few thousands char, we should be able to store some tens of thousands of keys - which sounds reasonable.

[alnr]

We have a bunch of other caches in the config schema already. Can you make your change so that it is more similar (identical) to those other cache configurations? The max_cost parameter in particular is really opaque and its impossible to come up with a reasonable value without knowing the implementation.

[David-Wobrock]

I agree with the remark on max_cost 👍
A value with similar semantics is used today for the OAuth2 introspection authenticator, so I mainly mimicked this one.
Else, there is also max_tokens, used by the OAuth2 client credentials authenticator.

I think the reason for the cost instead comes from the fact that the cached objects have variable lengths, so storing a certain number of objects will result in a different cache memory usage depending on your config.

However, one can also make the decision to let the user make this decision anyway :)
Let me know what makes most sense to you, and Ory's strategy around these questions (should the product have the same defaults for everyone, or is the user trusted to configure this accordingly).

---

For the enabled/disabled value, I didn't re-use the existing

    "handlerSwitch": {
      "title": "Enabled",
      "type": "boolean",
      "default": false,
      "examples": [true],
      "description": "En-/disables this component."
    },

to avoid introducing a breaking change.

Currently, the id_token cache is enabled by default, and didn't wanna change the default value to false - so I couldn't re-use this configuration.

---

And finally, this cache config has no TTL, because the id_token mutator already has a TTL config value for the JWT expiration date.
It make sense to me to re-use the same value => cache for 15 min if the JWT is valid 15min.

[aeneasr]

Ideally, we would probably have one namespaced cache for all of oathkeeper and then use that everywhere, but this is good for now!

[alnr]

In other caches, I believe we set the TTL to min(TTL, time.Until(expiresAt). That would make sense here too IMO.

[David-Wobrock]

They should be same normally. Since calling this method does:

	now := time.Now().UTC()
	exp := now.Add(ttl)
	[...]
	a.tokenToCache(c, session, templateClaims, ttl, exp, signed)

Or what am I missing? :)

[aeneasr]

LGTM

[aeneasr]

This only changes cache sizes and not the actual caching function itself, right? If so I think we’re very close!

[David-Wobrock]

This only changes cache sizes and not the actual caching function itself, right? If so I think we’re very close!

I'm glad to read this 😁

At the time of writing this patch does:

• behaviour changes:
  • set a TTL on keys in id_token mutator cache
  • set a cost function in the id_token mutator cache
• new configuration:
  • allow disabling id_token mutator cache
  • allow changing the cost of id_okten mutator cache

[David-Wobrock]

Hey @aeneasr I hope you're well :)

Did you get a chance to have a look again? 😇
We are still running our forked and patched Oathkeeper, but we would obviously prefer running the Ory upstream version.

Perhaps this can make it into the next version?

[David-Wobrock]

Hello @aeneasr @alnr,

A pity to see that we didn't make it into the latest Oathkeeper release 😞

Feel free to leave additional review to push this over the finish line 💪 I think we are not far 😄

[David-Wobrock]

The a.tokenCache.MaxCost() != cost condition is mainly for unit tests, in order to be able to test other max_cost values on the cache config.

On prod envs, this should not happen, and we'll keep skipping this branch.