You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every time we validate a session token, it makes a request to WorkOS's infra to get the same value from their systems to validate the token. On our end, we see each validation operation adds ~200ms to each request that performs a token check. Usually the key used for authenticity verification changes very infrequently so it's something that can be cached. The SDK could cache the key in a singleton on the server and use that and validate using the cached key optimistically. If the authenticity check fails, then it can call the endpoint to see if the verification key changed at WorkOS as a fallback, if it turns out to be a cache miss, then check the token and at the same time update the cache.
This should improve perf greatly on our end.
The text was updated successfully, but these errors were encountered:
Every time we validate a session token, it makes a request to WorkOS's infra to get the same value from their systems to validate the token. On our end, we see each validation operation adds ~200ms to each request that performs a token check. Usually the key used for authenticity verification changes very infrequently so it's something that can be cached. The SDK could cache the key in a singleton on the server and use that and validate using the cached key optimistically. If the authenticity check fails, then it can call the endpoint to see if the verification key changed at WorkOS as a fallback, if it turns out to be a cache miss, then check the token and at the same time update the cache.
This should improve perf greatly on our end.
The text was updated successfully, but these errors were encountered: