2

Let's say you're creating a banking web application with mobile apps. A bank user has permissions "transfer money" and "view balances." When a user logs in, we can create a session token (typical random string, stored in the database on the server and in a cookie or device storage on the client) with "view balances" permissions that lasts 24 hours.

However, "transfer money" is more sensitive so we could create a separate session token that expires in only 1 hour. If a user visits the site again in 12 hours, they'd still be able to view their balances, but they'd have to re-auth with the backend to transfer money. Then, for the next hour they could transfer money at will.

Is it advisable to create multiple session tokens with different expirations and different capabilities that co-exist in the client application? Is there a better solution?

Improve this question

3 Answers 3

Reset to default
0

Why not just store multiple expiration times server side? You already need server-side expiration time if you have a token that is not signed. Just add a separate expiration time for each capability and check that one on action.

For performamce reasons, you may or may not want a separate expiration time for the entire session, which would just be the longest one (to check whether to delete row from db).

Improve this answer
2
  • Is this not vulnerable to session fixation? It deviates from the principle of "issue a new session token whenever a user authenticates."
    – Prime
    Aug 14, 2019 at 19:07
  • 1
    No. I did not specify any renewal mechanism. You can still generate new sessions on authentication and delete the old one. This need not change anything in your authentication and session creation design, other than initializeing more columns.
    – Peter Harmann
    Aug 14, 2019 at 19:10
2

I have come across similar approach in complex applications which are microservice based. If different teams handle these services, having different session ID's tied to different capabilities can be a way forward. However it is not an elegant solution. The ideal approach should be to use the session for identification. The access control to a particular functionality can however be handled at the server side as a part of your authorization logic.

When a request comes in for making transfers have a server side logic to check for the following.

  1. Whether the user is authorized to perform transactions?
  2. Whether they have a session ID which was issued <12 hours ago?
Improve this answer
0

2 other solutions that I have considered:

Clientside Enforcement

Native Android & iOS applications support the concept of sensitive actions whereby the session token is stored encrypted in the keychain or equivalent, and can only be accessed by a user re-authing locally using their device PIN or biometric. A similar process is possible in web apps through the use of shortlived cookies created by the clientside application. This has the advantage of lower user friction, but the disadvantage of leaving enforcement of an authentication policy in the hands of the clients.

Re-auth on given routes every time

Simply force re-authentication every time a user wants to do a protected action like transfer money. This removes the need for multiple tokens, but it does create increased friction. If a user wanted to transfer money twice, they would have to enter their password twice in a row.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .