Refreshing session

[schreddies]

Hi Folks!
I would like to start discussion about making session refresh for Kratos more useful.

Current flow

Right now, according to documentation and my own experiments the refresh flow goes like this: user make request through API login for flow id, with flow id tries to login with credentials (/password) and then getting session token ends login flow. Next, she/he calls the flow endpoint with /?refresh=true with Authorization header including session_token and the new flow_id is created. Then it can be used as the id flow for next login call with credentials.

Expected

There is an endpoint, might be admin, when the similar call as for initiation login flow with ?refresh=true is performed including the authenticated user (via Authorization header) the session_token will be prolonged or new token with new expiration value will be issue.

[schreddies]

@zepatrik @vinckr FYI

[schreddies]

@aeneasr The security model behind that is similar to this form @zepatrik - if user is active, especially on mobile device (with other factors forced, like pin or biometry to unlock) we can prolong the session assuming that session is still active and user is still using the application. With requirement for session to be as short as possible we cannot force user to re-authenticate every 5 minutes but still she or he should be able to finish the business flow. Security measurement for that is the maksimum refresh/prolong session i.e. 3 times. Using short lived sessions (required) I would rather not to ask user every 5 minutes to re-authenticate. Theoretically, instead using long live tokens I am giving user the short live tokens and if application (or rather user) is still using it, I would like to prolong them. It is countermeasure for user leaving device unlocked and with valid session in the app, but still getting business flow done when it takes 15 minutes.

[aeneasr]

I see, that use case makes sense. I was always under the impression that the site would invalidate the session after 15 minutes but it probably makes more sense to have the session valid for only 15 minutes and be able to add another 15 minutes to it. So this wouldn't change the authenticated_at time, for example, it would just push the expires_at back for another 15 minutes. Did I get that right?

[schreddies]

I mean, short live tokens make more sense, especially in mobile cases, when user can exit the app without logging out and session will be still active.
@aeneasr Yes, you are right, basically it might prolong the expires_at time for n minutes, where n is the session time and with that user can use application using short-life tokens and still have same session_token.

[ghost]

@schreddies @zepatrik (Open Banking recommended flow for authentication). Sessions require a rolling timer in the front (usually web) detecting user gestures to determine to refresh or not the user session (usually at 3/4 of the maximum user authentication cookie or token is sent to be refreshed or reobtain a new one without using prompts) without re-entering credentials, otherwise it logs the user out. You can have a notification to keep the user logged in. On mobile, refresh tokens with PKCE for example stored in KeyStore Android or KeyChain iOS can be used to prevent full reauthentification, just local to access refresh tokens even after 2 weeks if the user has MFA. Correct me if i am wrong but Kratos /?refresh=true with session token does perform just that right ? Extend the user session ? I didn't quite catch why the new flow-id is created.

[aeneasr]

refresh=true will re-authenticate using a prompt so it requires e.g. presenting your hardware key, password, ...

[zepatrik]

Btw, this is tracked and discussed in #615