Implement Enhanced Backoff Policy for JWKs Retrieval and Validation

[tolgaOzen]

Context

This feature request relates to our OIDC implementation, which is located at /internal/authn/oidc within our Permify's repository.

Current Behavior

The system currently operates by fetching JWKs on a set timed interval. This mechanism does not support scenarios requiring urgent token rotation and may not be effective in mitigating abuse through the submission of invalid tokens.

Proposed Enhancements

1. Dynamic JWKs Fetching: Automatically attempt to retrieve the JWKs file from the PERMIFY server if it is not currently available.
2. Token Validation with KID Checking:
   • If a presented token's KID is not found in the existing headers, initiate a JWKs fetch and validate the token.
   • Implement a backoff policy as follows:
     • If the KID is absent in the header and it has been less than X minutes since the last JWKs retrieval attempt, reject the token as invalid without a new fetch.
     • If the KID is missing in the header and more than X minutes have elapsed since the last fetch, then retrieve the JWKs and validate the token.
3. Configurability: Allow these behaviors to be adjustable through configuration settings, enabling customization of the backoff timer and response strategies to fit varying security and operational requirements.

Rationale

This enhancement aims to bolster security by facilitating urgent token rotation and preventing potential abuse scenarios without overwhelming the JWKS server with requests due to invalid token submissions.

Suggested Libraries/References

We are using the lestrrat-go/jwx/jwk library for JWK handling.

Timeline

Urgently needed by Wednesday (20.03.2024) to meet security and operational standards.

Request

We are seeking feedback on this proposed approach and would appreciate any support in implementing these changes. Thank you for your attention and assistance.

[tolgaOzen]

/bounty 300

[algora-pbc]

💎 $300 bounty created by Permify
🙋 If you start working on this, comment /attempt #1135 along with your implementation plan
👉 To claim this bounty, submit a pull request that includes the text /claim #1135 somewhere in its body
📝 Before proceeding, please make sure you can receive payouts in your country
💵 Payment arrives in your account 2-5 days after the bounty is rewarded
💯 You keep 100% of the bounty award
🙏 Thank you for contributing to Permify/permify!

Don't wait to be assigned. A reward will be given for the best PR.

👉 Add a bounty • Share on socials

🔴 Livestream on Algora TV while solving this bounty and receive $200 upon merge!

Attempt	Started (GMT+0)	Solution
🟢 @ahmethakanbesel	Mar 19, 2024, 9:09:40 AM	#1137

[Bhavyajain21]

I would like to give it a try, can I be assigned? @tolgaOzen

[abhishek818]

Adding myself in queue..

[Lemmynjash]

Adding myself in the queue as well

[ahmethakanbesel]

/attempt #1135

Options

• Cancel my attempt

[algora-pbc]

💡 @ahmethakanbesel submitted a pull request that claims the bounty. You can visit your bounty board to reward.

[ioneyed]

@tolgaOzen - I noticed one of the features was

Implement a backoff policy as follows:
If the KID is absent in the header and it has been less than X minutes since the last JWKs retrieval attempt, reject the token as invalid without a new fetch.
If the KID is missing in the header and more than X minutes have elapsed since the last fetch, then retrieve the JWKs and validate the token.

I do not see anything in the merged PR #1137 that adds the backoff strategy or even retries the JWKS attempt if the KID is not found but rather just failing to authenticate. I see that it handles the auto-refresh but not the backoff part of the needs.

There are scenarios where the AutoRefresh works great but if that interval is say 4 hours based on a regular rotation of keysets. However, if a key rotation needs to happen in between the caches refresh time due to a security incident then the user will still have a failure due to the KID not being present in the keyset.

One could say that you should set the refresh timer to a low number (5 minutes) so your maximum outage of a key rotation is low, but that is also making Permify a bit chatty when it doesn't have to be if there is some logic to refresh if a new KID is presented that isn't in the keyset and it has been more than backoff: time.Duration. If a new KID has been presented but the last keyset fetch was under backoff timer, then it fails the authentication call as a bad token. This allows longer periods of caching (i.e 4 hours) 99% of the time, with the backoff be a failsafe during a security event.