Revisit the concept of User Sessions

[htdvisser]

Summary:

We need to discuss what to do about the concept of user sessions.

Why do we need this?

There is to much confusion about user sessions, logins, logouts, etc.

What is already there? What do you see now?

In addition to the OAuth server, all OAuth clients (CLI's and consoles) also have their own login/logout. Logins to an OAuth client result in an OAuth authorization (if not already authorized), as well as an OAuth access token and typically an OAuth refresh token (hereafter simply OAuth tokens). Logouts from the OAuth client result in a revocation of the OAuth token of the current session of the current user on the current client.

Logouts from a user on an OAuth client do not revoke other OAuth tokens of the same user on the same OAuth client. This means that if I am logged in with the Console on two different laptops, and I logout on one laptop, I'm still logged in on the other laptop. This makes complete sense to me. If Airmail on my MacBook and on my iMac are both logged in with my Google account, and I logout of one, then the other is still logged in.

Logouts from a user on an OAuth client do not revoke other OAuth tokens of the same user on a different OAuth client. This means that if I am logged in with the Console and CLI, and logout from the console, I'm still logged in with the CLI. This also makes complete sense to me. If Airmail and Contacts on my MacBook are both logged in with my Google account, and I logout of one, then the other is still logged in.

Logouts from an OAuth client do not revoke the user's session on the OAuth server. This means that if I am logged in with the CLI, and then logout, I may still be logged in on the Identity Server. Again makes sense. If I logout of my Airmail, my browser is still logged in to google.com.

And finally, logouts from the OAuth server do not revoke OAuth tokens. This makes complete sense with the Google example. If I logout from google.com, my email doesn't suddenly stop working. So this should be the same for our OAuth server. If I logout from the Identity Server, my Console sessions in my 3 browsers shouldn't be affected, right? And the ones on my iMac? Oh but wait, I'm still logged in to the OAuth server on my iMac! This is how people lose their minds.

Oh and things will get even worse when we'll have a multi-region Identity Server 😏

Enough?

What is missing? What do you want to see?

I think we should extend the UI of the Identity Server with a page /account that looks like this:

This will allow users to manage their sessions (direct logins to the OAuth server / Identity Server), manage client authorizations and allow them to revoke OAuth tokens.

---

I think all logouts should (after doing the usual revocation of OAuth tokens) redirect the user to that account page on the Identity Server where they can decide what to do about other sessions and OAuth client authorizations. We could even build something that allows us to filter OAuth client authorizations and OAuth tokens by the session that created them.

[htdvisser]

Updated title and description. @johanstokking @kschiffer comments please.

[johanstokking]

I think it's good to work towards a screen like that, but I see a complicated solution for a simple problem.

That is, if you logout in an OAuth client (i.e. CLI or Console), and you log back in, the OAuth server logs you in automatically, so you don't have a chance to switch accounts.

Right?

Isn't that fixed by the switcher in #488 ?

[kschiffer]

Note that google apps essentially solve this by integrating the account switcher into their apps:

It also means that clicking logout there will actually log you out from your google account altogether, which is in line with what users likely expect to happen. I think a solution like this would be very nice to have in the console because it is very clear to the user and would solve the login/logout confusion, because people will have a hard time understanding the separation of oauth server and console app. So from a user perspective, this will tie the two closer together.
However, I can't assess whether this solution would be possible with our current setup.

So this is a solution for "first-class" applications like the console. Third party apps would still need to rely on a dedicated account switcher.

[johanstokking]

I agree that having the OAuth client logout actually go to the OAuth server is a shortterm and effective solution.

[johanstokking]

So what do we decide here?

[htdvisser]

I think we should do (in order)

1. After console logout, redirect the user to a logout page on the OAuth/Account UI, something like /oauth/logout, but we may want to look at how other systems such as OIDC do this (this issue)
2. Before the OAuth Authorize, we should add a screen that asks the user if they want to continue as (Account Switcher on OAuth Server #488)
3. On the OAuth/account UI, show where else a user has valid OAuth access tokens (other CLI/Console/... logins) and allow the user to revoke those too (this issue).

[johanstokking]

OK sounds good.

[kschiffer]

After console logout, redirect the user to a logout page on the OAuth/Account UI, something like /oauth/logout

So this would be a simple page with a logout button?

Before the OAuth Authorize, we should add a screen that asks the user if they want to continue as (#488)

I often see a message like these on authorization pages: "You are currently logged in as USER_NAME" and then a link to switch the account. The problem for the console being that we skip the authorize screen altogether, so we can indeed only solve it by adding an additional screen.

[htdvisser]

1. For the MVP yes, it would show who is logged in, and a logout button. Like what we have now, but then fancier.

2. Yes, for every client that is pre-authorized or previously authorized by the user, the screen is skipped. This is per spec. There would indeed be an extra screen "continue as " before the authorize screen (which is still skipped for already authorized clients)

[htdvisser]

Replaced by #1422.