Re: [keycloak-dev] Password Updates and Authenticators in the new Account Console

Just to be precise – what I called Required Actions are actually Application Initiated Actions (AIA) [1]. Which is technically almost the same as Required Actions with the difference that it's initiated by the application and not by the login process. [1] https://github.com/keycloak/keycloak-community/blob/master/design/applica... On Thu, Aug 22, 2019 at 5:40 PM Václav Muzikář <vmuzikar(a)redhat.com&gt; wrote: > Hello, > I wanted to discuss the new Account Console which is in development and > how it handles password updates and authenticators configuration (e.g. > TOTP). > > Currently, when a user wants to update their password [see attached A.png] > or configure authenticator [B.png] they cannot do it directly from the > Account Console. They need to be redirected back to Keycloak and perform it > there in form of Required Action [C.png, D.png] – which is technically the > login screen (it uses the same template). This also means there will be no > REST endpoints for changing passwords or managing authenticators. > > IMHO this is not the best approach either for users or developers (who'll > be using Keycloak with their app). Let me explain why. > > - It's not really user friendly. Redirecting from one application to > seemingly completely different application is never good and can be > confusing. I can imagine some less tech savvy users could even feel "in > danger" – one second you're securely managing your account and then you are > asked to change your password in some other application (that suspiciously > uses the same design as login screen). > - This approach doesn't feel seamless. You can change e.g. your name, > email, etc. directly from the Account Console. But not password and > authenticators... > - It's not an industry standard. I haven't ever encountered anywhere > that I'd have to be redirected from some profile managing app to completely > different app just to change password. Again – it's confusing for the users > to do something differently than they're used to and what they expect. > - Network traffic overhead. People accessing the Account Console will > often use some limited and slow internet connection. Needless redirecting > back and forth and loading the application again takes data and time. > - Missing REST endpoints limit developers. With a proper REST API devs > could e.g. fully integrate the Account Console functionality into their own > app (and effectively replacing the Console by their app). This also means > no CLI apps support. And I don't think REST API is less secure than > Required Actions – either way you're sending an HTTP request and how it's > secure depends on the same factors for both. > - We're stripping out core Account Console functionality. It was > always a central place to manage your account. Now it can do what? Change > your email and manage apps access? (We could as well replace it with bunch > of links to Required Actions. :P There're are already Required Actions for > changing email and name.) > > I can see however one advantage of this approach. There's only one place > where users can change their passwords and authenticators – no need to > implement it second time when it's already implemented as Required Actions. > But this is actually not entirely true as e.g. password changing process > (incl. password policies etc.) is implemented in Admin Console too so there > needs to be some shared logic. > In general this approach practically benefits "only" the implementation > complexity – it's easier to do it this way and therefore less error prone. > > WDYT? Should we keep the current approach? > > Thank you! > > V. > > -- > Václav Muzikář > Senior Quality Engineer > Keycloak / Red Hat Single Sign-On > Red Hat Czech s.r.o. >