Introduce new account app (to replace oauth app)

[kschiffer]

Summary

We currently have a lot of issues revolving around our OAuth flow, account switching, token management, respective branding, etc. This is an attempt to make all of these more actionable under a new account app that will take care of all of these concerns.

Why do we need this?

• Missing account switching functionality ⟶ Account Switcher on OAuth Server #488
• Missing branding and context for the user ⟶ Add simple "logged in" screen and branding to OAuth app #730
• Missing session management ⟶ Web UI support for OAuth Client Authorization and Access Token Management #1217
• User confusion around OAuth authentication flow ⟶ Revisit the concept of User Sessions #265

What is already there? What do you see now?

• OAuth app with limited UI

What is missing? What do you want to see?

An app that acts as OAuth provider and fully featured and branded configuration UI around all account and authentication concerns

Environment

Web

How do you propose to implement this?

I think a big problem with the current implementation is the lacking clarity and context for the user. It is hard to recognize the OAuth app as an independent authentication entity. Reasons are:

• lack of branding and context
• very reduced and uninformative UI
• console acting as if it handles authentication itself ("Login" message instead of "Login with your {OAuth provider service name} account", skipping of authorization)
  To improve clarity, we need to make the app more visible, distinguishable and purposeful:
• Add configurable branding
• Flesh out functionality
  • Account switching
  • Session management
  • Authorizations management
  • Profile settings (change/forgot password, email, profile picture)

I've created three wireframes that give an idea of how I envision the account app:

See wireframes

(notice the account switcher integrated in the user dropdown in the top right)

Can you do this yourself and submit a Pull Request?

Yes. @johanstokking @htdvisser, please let me know whether you think its good to continue.

[johanstokking]

References https://github.com/TheThingsIndustries/lorawan-stack/issues/1659

[kschiffer]

Regarding the whole login/logout confusion issue between console and oauth provider, here's my plan:

• We use a separate Account logo for the account app (instead of the TTS Logo) and use the same header component which we also use for the console (cc @pierreph)
• Instead of having two separate login screens for console and account app, we should tie the experience closer together, meaning
  • We will remove the console login screen /console/login
  • The console will automatically redirect to the account app login page /account/login, when it has no (valid) access token
  • Like we already do with the console login button, we will use a redirect query param to send the user back to the console after successful login
  • Logging out from the console UI will result in removing the stored access token, as well as logging out from account app. This way, users will always have to re-enter their credentials in order to log back into the console.
    • To be able to do this, we need a way to trigger logouts from cross-origin requests (since console and account app are not guaranteed to be on the same origin)
    • In v2, we're using a simple /users/logout route that will trigger a logout which can be referred to from anywhere
    • Would be good to look into ways to achieve the same thing while staying CSRF safe
  • The new flow will pretty much resemble the flow of the v2 console; we'll basically sacrifice the separation of console client and authorization server to improve the UX, which is OK since the console is sort of a special case client
  • We might need to revise this flow if we allow for different login procedures in the future

If I don't hear any complaints about this plan I'll start implementing this.

[johanstokking]

Sounds like a great plan. I agree we don't need explicit logout of Console and stay logged in via OAuth in the UX, although it will work that way underneath.

What do you need for cross-origin logout? Wouldn't it be a simple two-step approach; logout "page" to remove Console stored access token, then redirect to generic logout page where the Account app logs out? Or do you want this without redirection but post to a logout endpoint?

[htdvisser]

For logout, we can get some inspiration from OpenID Connect logout. Nice summary can be found here: https://medium.com/@robert.broeckelmann/openid-connect-logout-eccc73df758f

[kschiffer]

Sounds like a great plan. I agree we don't need explicit logout of Console and stay logged in via OAuth in the UX, although it will work that way underneath.

What do you need for cross-origin logout? Wouldn't it be a simple two-step approach; logout "page" to remove Console stored access token, then redirect to generic logout page where the Account app logs out? Or do you want this without redirection but post to a logout endpoint?

Two-step approach is OK. My concern was that the logout of the account app needs to be CSRF disabled, meaning that anyone with a logout link could lure someone into logging out from their account. This is also currently possible with the v2 stack (clicking here will log you out).
I think for now this is acceptable but not exactly best practice.

[kschiffer]

I've done quite some work now for the new account app:

• Refactored components and containers that can be used by console and account app
• Implemented new designs (including responsiveness)
• Implemented profile settings, including profile picture
• Implemented authorizations management (view and revoke)
• Implemented session management (view and revoke)
• Resolving an issue that resulted in blank renders when using shared css module dependencies

I did this by hardcoding an access token, to be able to use the stack API. I'm currently unable to advance with a proper implementation, since I don't know what would be the best way to obtain an access token for the account app.
Right now, the "oauth app" is just a SPA that connects to the auth endpoints of the oauth server (login, logout and other account related endpoint that do not need an access token).
@htdvisser mentioned to me that our initial idea was to have the account app as separate oauth client, using the password grant type. I think we should open a discussion about this, since:

• depending on the source, the password grant type is discouraged, even for "official" and trusted clients
• it would necessitate another login screen (next to the login screen of the oauth provider)
• I'm wondering whether there is a way to get an access token from the oauth provider directly, without having to use another separate client, since we're already doing authentication inside the oauth app
• if we use the password grant for the account app, we should use it for the console as well

I already said to @htdvisser that the whole delegated authentication/authorization aspect of this is somewhat overwhelming to me and I don't feel knowledgeable enough to be responsible for such a security-sensitive matter.

What we should aim for is a flow that makes the authentication flow of our official clients feel like native authentication (see also my other comment), meaning that logins and logouts are global and there should be no distinction between the authenticated state of the clients and the authorization provider.

So, I'd need some help and input to go on with the account app. How can we coordinate this?

[johanstokking]

depending on the source, the password grant type is discouraged, even for "official" and trusted clients

Yes, password grant must not be used, see specification and reasoning here: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.4

[johanstokking]

@kschiffer what is the status here?

[kschiffer]

Currently rebasing my work on the new scaffold, which is ongoing here: #3453

Next up is rebasing, fixing and PRing the authenticated views and adjusting the current designs to the new branding.

[johanstokking]

@kschiffer what is the status here?

[kschiffer]

The Account App has been introduced in 3.11. Currently still missing are:

• Account switching Account Switcher on OAuth Server #488 
• Session management 
• Authorizations management (iirc this also includes adding API endpoints)

[johanstokking]

OK. #488 is already closed it seems.

This has been a big issue. Can you file one or two new issues for the above to replace this one, so it can be closed?