MSC 1466 - Soft Logout

[erikjohnston]

Rendered

[ara4n]

+1 to this existing. should we think of it as a “re-auth” API though rather than a soft logout? A logout which doesn’t delete your local state is horrid. But how about a “re-auth” API which clients should use to display a new auth popup over the top of the logged in user... and then vape the local storage if that auth fails?

[erikjohnston]

+1 to this existing. should we think of it as a “re-auth” API though rather than a soft logout? A logout which doesn’t delete your local state is horrid. But how about a “re-auth” API which clients should use to display a new auth popup over the top of the logged in user... and then vape the local storage if that auth fails?

We can certainly change the name of the property, though its worth noting that one of the use cases for this is so that we log people out due to e.g. server hitting its resource limit, and so they would be unable to log back in again. Not sure if it would therefore be confusing to call it "re-auth" if they're actually properly being kicked off the server

[ara4n]

The distinction i am aiming for is that the API would mean “you cannot continue to use the app until you reauthenticate” rather than “you have been logged out of the app, but your data has silently been left hanging around your client”. And the UX could make this clear on the client - ie showning the reauth as a popup over your logged in state, to make it clear to the user that they need to clean up that data manually themselves if they fail to auth. However, why are you doing a logout when server limits are hit? Shouldn’t you just start returning errors from write operations (like we do for gdpr if you’re not authed)? A logout or reauth is pretty drastic!

[erikjohnston]

As described in the proposal this flag will allow clients to differentiate different the two cases and handle them differently in the UI, regardless of what we name the flag. Personally, I think "reauth" doesn't necessarily accurately describe what's potentially happening, but its a good a name as any I can think of.

[dbkr]

Summarising from the Matrix chat, my plan on Riot was to make this the way it handles logout anyway. Personally I think if you wanted to request the client delete key material, that would probably be a separate 'remote wipe' thing.

[erikjohnston]

Personally I think if you wanted to request the client delete key material, that would probably be a separate 'remote wipe' thing.

My hunch is to get it to work we'd end up having to have a flag on the 401 responses anyway, so I think we're in agreement (other than perhaps what to call the flag)

[dbkr]

Yep, I suspect it would be a flag in the same place so it's basically just what the flag is called and the default if the flag isn't there.

[erikjohnston]

Does anyone have any opinions on what the default should be?

[aaronraimist]

For me ideally it would work something like the Google login/logout screen. When you log out it would show you both an option to log back in to the same account and an option to login to a new account by default on every log out.

[ara4n]

I suggest the default should be soft_logout=false for compatibility with what we have today. I seem to be alone in wanting to call it re-auth, so ignore that.

@dbkr said:

Summarising from the Matrix chat, my plan on Riot was to make this the way it handles logout anyway. Personally I think if you wanted to request the client delete key material, that would probably be a separate 'remote wipe' thing.

I'm really not sure we should be leaving key data hanging around by default, but only if the server has explicitly said "please re-authenticate the user without logging them out" (i.e. a "soft logout").

[erikjohnston]

I think the conclusion was to default to soft_logout=false if its not specified, so:

@mscbot fcp merge

If people have concerns with that then shout. I think we have enough alignment on the UX such that whatever we decide to do there it won't affect the API shape.

[mscbot]

Team member @erikjohnston has proposed to merge this. The next step is review by the rest of the tagged teams:

• @KitsuneRal
• @anoadragon453
• @ara4n
• @dbkr
• @erikjohnston
• @richvdh
• @turt2live
• @uhoreg

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[uhoreg]

Under what conditions would soft_logout be set to true? I'm guessing changing the user's password would be one situation? Are there others?

[erikjohnston]

Yup, or to allow us to time out old session, etc. Another case is when you want to force users to go through the login flows again, e.g. as an easy way to get a user to accept new ToCs.

[uhoreg]

Makes sense. It would be nice to list some examples in the Motivation section. But other than this and the typo, lgtm.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.