Caching session data for access token

Help
, , ,
1

Hi,

When an SPA (for example) is refreshed, auth0-spa-js performs a prompt=none silent authentication. This hits auth0.com and which maintains the same session (context.sessionID).

Where a rule has prepared and added additional data to the access token in the original login, it would be ideal to cache this data so that it could be trivially re-added in the prompt=none silent authentication case.

What is the recommended strategy to accomplish this?

Thanks,
Daniel

PS Any update on the “more stable session identifier available in rules” feature?

2

Starting from below I’m afraid I don’t have any news in relation to the stable session identifier; what I can share is that it is something not being worked on at the moment so unlikely to be available in the short term. About when/if it would be available I’m unable to provide any useful information.

In relation to caching data relevant to the authentication/authorization request you can consider using the initial login rules to persist that info as part of app_metadata. Subsequent executions can then choose if the available data (likely through the inclusion of a timestamp) can be reused or if it should be re-generated from the source. I would not go so far to say this would be the recommended strategy as it can depend on the data in question. However, if it’s data that is being included in the access token (issued for an end-user) then it seem app_metadata which is also associated to the user could be relevant.

3

Thanks @jmangelo, appreciated.

Not ideal news on the stable session identifier update :frowning:, but thanks for letting us know. My observation from examining the log entries is that you have the relevant IDs, but they are just not exposed presently…

Regarding caching based on timestamp, this is the direction I was going using context.authentication, something like the following to generate a reproducible session ID with hopefully low chance of collisions:

let __sid = [ user.user_id, context.clientID ];
if(context.authentication.methods) context.authentication.methods.map(m => {
  __sid.push(m.name); __sid.push(m.timestamp);
});
__sid = __sid.join('.');

Let me know any comments / advice.

Obviously, cleanup needs to be managed.

4

I confess I took the two original points as independent, but I believe the original goal would be to have a stable session identifier so you could cache per session and due to the lack of a built-in identifier in rules you’re crafting one based on other context information.

In relation to your method for calculating that identifier I would prefer not to weigh in with a general opinion if it’s correct or not as the correct thing would be a built-in identifier. However, in the absence of that I can make a few personal comments.

In particular, technically a session should be independent of client identifier, although your logic makes use of that identifier. This may be relevant to your use case, but for completeness I’m calling that out.

I also could not find any documentation guaranteeing that the order in which context.authentication.methods is provided is consistent. In other words, for robustness to changes you could consider explicitly sorting that array so you ensure you join the methods consistently even if the order in the array is not consistent.

1 Like
5

Apologies for the unclear link between the two original points.

Regarding a session should be independent of client identifier - I hear you - in this case, I was aiming to have maximum discrimination (and lowest possible chance of cache collisions) to cover the case where a user initiates login for multiple applications/clients at the same time. Obviously agree, the ideal is a built-in identifier.

Your note regarding order is an important factor I’d omitted.

Thanks for the feedback.

1 Like