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

[Stan Silvert]

Vaclav makes some good points below. Stian and I have discussed this 
before, but now that AIA is implemented in the console, it brings the 
issues to the fore.

I'm not overly concerned about performance of redirects right now.  
There is a lot of work that will be done to shore up the performance of 
account console.

But the point still stands that it's a bit weird to have an app that 
uses REST for some things and AIA for other things.  As Vaclav says, it 
might make more sense to do everything with REST or everything with AIA.

One question I have is if other developers will be bothered by the lack 
of a REST API for things like password changes.  Do we think we know the 
answer?

Stan

On 8/23/2019 2:43 AM, Václav Muzikář wrote:
> 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.
>>
>