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

[Václav Muzikář]

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/application-initiated-actions.md

On Thu, Aug 22, 2019 at 5:40 PM Václav Muzikář <vmuzikar at redhat.com> 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.
>


-- 
Václav Muzikář
Senior Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.