Reduce the number of core calls related to refetching claims values from the DB

[porcellus]

🚀 Feature

Reduce the number of core calls related to refetching claims values from the DB. There are some features of the claim validators that have confused some of our users:

• automatically refreshing claim values from the DB based on validators attached to API endpoints
• claim values not getting refreshed in refreshSession calls

We aim to simplify this flow by:

• Moving all automatic claim value refetching into refreshSession
• Dropping claim value expiration checks

Implementation details

Move all refetches into refreshSession

Option 1 - respecting backend SDK overrides

• Refetch all global claims (same as those added in createNewSession)
• Add a new parameter to refreshSession core call to specify claims to be automatically refetched
• After the refresh, we can check if there's an override for any claim builder and refetch values
• Call regenerateAccessToken to update claims if necessary (if the payload added by the builders do not match the refreshed payload)
• Extend this to createNewSession as well (to reduce core call counts during sign in/up)

Option 2 - adding all claim values by default

• The core can add the values for most built-in claims (email verification, roles, permissions)
• This inflates the token size by default
  • The size issue can be fixed by adding a param to the core call that will either disable the generation of those claims, or that will be merged into the token (so passing st-ev: null would remove the email verification claim)
• The issue with this is that it skips all backend overrides

In getSession/verifySession

• Drop all expiration checks from claim validators
• Return 401 if a claim value is missing
  • This will help with migration
  • TODO: this could trigger a refresh loop if the refresh call is not actually adding the claim
• Return 403 if a claim value is invalid
  • This can only mean that the value is set and it has the wrong value

Dropping claim expiration checks

• We can say in the documentation that if you require an up-to-date value you can check it yourself in the API/UI code
  • We could keep the fetchAndSetClaimValue as a convenience function on the session object for this
  • The frontend can trigger claim refreshing by refreshing the entire session
• It lines up with tying the claim validity to the access token lifetime