Support max-age cookie expiration, fix impossible to sign-in

[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 https://github.com/openid/AppAuth-Android/issues/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 your provider, 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:

• The app or flutter_appauth reads the _session cookie that points to "a dead" user information. 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 perhaps in additionalParameters, so that the _session cookie auto-expire. Note: 0 must be int not type String so not sure if is parsed correctly under-the-hood

[michelerenzullo]

It might be the case that this is not really flutter_appauth issue, but more AppAuth0 or LogTo (provider), I'm not sure but please feel free to close it if you agree. For other devs that have similar issue, I opened a new issue in LogTo: https://github.com/logto-io/js/issues/765

[MaikuB]

From what I understood, what you're referring to is around details set in the session cookie. If so, cookies are to do with the identity provider you're using as they would be the one response for providing the cookies and handling the cookies properly. This would be outside the control of the plugin. Note the plugin itself doesn't read cookies either. Rather, it's browser that does so. Perhaps you've already tried it but it could be the only option is to see if you can catch this specific issue to trigger a logout first. Perhaps the cookie could be detected that it can be used to trigger logout that would then in turn would remove the cookie

[michelerenzullo]

The issue is that sometimes the user uninstall the app without doing a logout, so the _session cookie is persistent in the browser, so I think is that this cookie keep a corrupted information, like an hash, because the user it belongs to has been deleted so the identity provider I think try to test with something that doesn't exist anymore and fails. More about and video here, perhaps together we can understand what's going on. https://github.com/logto-io/js/issues/765

[michelerenzullo]

I think there isn't a way to detect in your app programmatically which cookies has the browser or WebView and if are related to my identity provider, the solution so ugly would be to force an endSession when you login and then straight a new signIn, but this will interrupt the flow and will show 2 WebView or other times, when no _session cookie exists, the first step, in this case endSession will fail

[MaikuB]

That is the solution I'm referring to on detecting the invalid grant error to trigger a logout. Whilst it isn't ideal, you may not have much choice. I believe this was also a scenario myself and others encountered when worked with Azure B2C. It wasn't exactly though but pretty similar and if you're worried but the scenario too then this be one you'd probably want to keep an eye on too. In this case, a user was deleted whilst they had an active session in the app. The next token refresh would fail as the user had been deleted. This was also solved by detecting an invalid grant error to trigger a logout. Based on this I believe you don't have much choice but to do the same. A search online seems to indicate the invalid grant can occur when users are deleted for other providers. IMO it is also an edge case so whilst it is "ugly", I'd suggest being careful on investing too much in searching for a ideal solution that may not exist. Worst case if a user was really impacted by it and support is needed, they can be advised to clear the browser cache

[michelerenzullo]

Yeah, I think we gonna implement this for now since we can't leave unimplemented the delete user feature in our app, and hopefully the identity provider will find a better workaround. Sounds quite similar to your issue with Azure