bug: _session cookie of deleted user not invalidated, feature: cookie max-age

[michelerenzullo]

Problem:
There is a specific circumstance where it's impossible to sign-in anymore till the deletion of _session cookie in Chrome(Android) or Safari(iOS), even if the prompt=login.
Related issue here openid/AppAuth-Android#874 and how it is solved

Steps to reproduce the issue, assuming you have a signin with auto code exchange and prompt=login, i.e should always force a new login:

1. You log-in in your app
2. You clear the data / uninstall app
3. From LogTo, you must delete the account where you logged in at step 1
4. Open the app and try to login: you get always "invalid-grant"
   PlatformException(authorize_and_exchange_code_failed, Failed to authorize: [error: invalid_grant, description: grant request is invalid], null, null)

What would be the correct flow:

1. //
2. //
3. //
4. You should be able to login again, because prompt=login should be a guarantee that any (corrupted or not corrupted)_session cookie previously stored in the browser won't prevent you to login again

Explanations:

• Seems that somehow is read the _session cookie that points to "dead" user information (deleted). The user will not be able to login anymore till he manually delete the _session cookie in Chrome.

Possible solution:

• Find a way to set max_age: 0 along with prompt=login, so that the _session cookie auto-expire. In the specs there is actually an OpenID param called max-age or max-auth-age but I'm not sure LogTo implement it.
  You can notice, in the photo below that _session is valid for 2 weeks from login, it should be always 0 when prompt=login is used

[michelerenzullo]

In order to don't break the user sign-in flow after a user deletion, we should either:

• Workaround / Feature "maxAge": this will tweak the _session cookie so that is not always 1_209_600 but is maxAge dependant.
• I think that, when prompt=login, _session cookie should never be parsed/validated, because everything related the previous session can be safely ignored.
• If still, for some reason, we want to validate the _session cookie even if prompt=login, we should definitely find a way to don't throw an exception when the user info associated to the _session cookie doesn't exist anymore

on iOS a temp workaround to this issue is to set ephimeralSession true, but is not possible on Android and also is not something nice, since the browser have stored the connectors account (like AppleID / Gmail) to be easily tapped

[michelerenzullo]

I tried to pass "max-age":0 or "max_age":0 but is still setting _session cookie expiration after 2 weeks

[michelerenzullo]

Is there any update about?

[wangsijie]

@michelerenzullo I'll take a look soon.

[wangsijie]

Hi @michelerenzullo,

I attempted to reproduce the issue but was unsuccessful. Here's my process:

1. Signed in as user1 and redirected to the application
2. Deleted user1 via the admin console
3. Cleared the application's local data (specifically, the localStorage)
4. Reloaded the application

Result: I was redirected to the sign-in page. The password form appeared without any errors. This behavior is expected because the server automatically invalidates and clears the session for the deleted user.

Let me know if you need any clarification or if you'd like me to try a different approach.

[michelerenzullo]

Hi @wangsijie ,

I believe there is something different in your environment, for app I mean any android or iOS application . The "_session" cookie is stored in Cookie Tab of Chrome or Safari (you can use Dev tools and remote debugging from your laptop). Even if you delete local storage, the cookie is still present and is erased only when doing an endSession on the endpoint of LogTo. Let me know how can I help you to reproduce, I will think something more advanced in a bit.

[michelerenzullo]

The _session cookie is still holding the userID information has an hash, because this is verified in LogTo and it throws an error. The _session cookie can't be directly "deleted" because LogTo has no access to Chrome or Safari, only if executing an end session request this is erased, but this option is excluded since (point 2) the user deleted the app

[wangsijie]

I can confirm that _session exists in my browser, and it was sent to the server.

I'll do another test in native application.

[michelerenzullo]

Hi, is there any update about this issue? Thank you

[xiaoyijun]

Hi @michelerenzullo , I just have a test, but I can't reproduce.

session-test.mp4