What is the best way to implement sliding window expiry using the same tokens for an API client and an MVC client

Help
, ,
1

We are migrating from a MVC application to a SPA/API based one, and am needing to support the user requesting pages from both in the same session. That is, my business rules are:

  1. Shared Auth - when a user logs in, she should be able to navigate between the SPA/API Web Client or MVC client and maintain her state of being logged in (or out)

  2. Shared Activity - if a user is active in either the Web Client or MVC client, then the sliding window expiry should account for it in the idle timeout.

  3. Idle Timeout - If the user is inactive in both for > 30 minutes, they should be required to re-authenticate

We’ve come up with a few solutions, and I’m needing to validate what the best approach is.
Our idea is to work with a pair of tokens: a long lived access_token and a JWT token

  1. When the client logs in and receives the tokens, save it in the local session storage and also send it to the MVC app to set in the server session cookie

  2. When the client makes a request to either the API or the MVC endpoints, either endpoint will
    a. check if the JWT token is expired. If so, return with a 401 authentication required
    b. else (if the JWT token is valid): send an asynchronous message to Auth0 with the token, telling it to update the last_accessed_at timestamp. In Auth0, it will associate the token with the timestamp. (that is, don’t associate the user with the timestamp to accommodate if the user has multiple sessions)

  3. If the client receives a 401 authentication required (from 2a), it will send a request to Auth0 to re-authenticate. An Auth0 rule will be set up that will check if the current_time - last_accessed_at timestamp (from 2b) < idle_timeout. If it isn’t, it will regenerate a new token and send it back. Alternatively, if the current_time - last_accessed_at timestamp exceeds the idle_timeout, it will ask the user to re-authenticate and send back the new_token. The client will receive the new tokens and update the local storage and server session cookie again as in 1.

Questions:

  • Is this a valid, safe approach to solve the problem?

  • Can I set up an access point for 2b to relay back to Auth0 when the user’s last activity was?

Thanks in advance.

2

As it has been more than a few months since this topic was opened, and there has been no reply or further information provided as to the existence of the issue, we are closing this topic. Please don’t hesitate to create a new topic if this issue is still present, we would be happy to work with you to help find a resolution.