Add 30s cache to SSO exchange_refresh_token #94

Closed
opened 2026-04-05 20:29:57 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @Timshel on 2/23/2026

This add a cache to the refresh_token endpoint to prevent calling a provider twice with the same token (some providers prevent reuse).

I contributed a patch to the clients to prevent the issue https://github.com/bitwarden/clients/pull/10799.
But it appears some users still have issues: Ex: https://github.com/dani-garcia/vaultwarden/issues/6311#issuecomment-3775829084.

Looking at the client code I couldn't identify how to reproduce the issue :(.
But at the same time the fix is relatively trivial, so I believe it's worth to integrate it (Only issue I could see is it'won't work in multinode setup unless some affinity is set at the loadbalancer).

Switched to Moka to be able to use get_with.
Did not change the current CLIENT_CACHE since it's not an issue if two clients are instantiated and ApiResult is not Cloneable so it would be kind of a pain to replace.

The capacity is a bit random just though it was better not to let it unbounded and the 30s should be way enough to handle any concurrent calls without keeping it around too long which would negate the utility of rolling tokens.

*Originally created by @Timshel on 2/23/2026* This add a cache to the `refresh_token` endpoint to prevent calling a provider twice with the same token (some providers prevent reuse). I contributed a patch to the clients to prevent the issue https://github.com/bitwarden/clients/pull/10799. But it appears some users still have issues: Ex: https://github.com/dani-garcia/vaultwarden/issues/6311#issuecomment-3775829084. Looking at the client code I couldn't identify how to reproduce the issue :(. But at the same time the fix is relatively trivial, so I believe it's worth to integrate it (Only issue I could see is it'won't work in multinode setup unless some affinity is set at the loadbalancer). Switched to `Moka` to be able to use `get_with`. Did not change the current `CLIENT_CACHE` since it's not an issue if two clients are instantiated and `ApiResult` is not Cloneable so it would be kind of a pain to replace. The capacity is a bit random just though it was better not to let it unbounded and the 30s should be way enough to handle any concurrent calls without keeping it around too long which would negate the utility of rolling tokens.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/vaultwarden#94