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

[Stian Thorgersen]

That being said. For the first version of API and UI we will stick with AIA
for everything that has to do with credentials. We can consider in the
future to add direct API and UI for some actions. End of the day though
it's not an action users do very regularly and the additional complexity
and potential security implications probably makes it not worth it. Also,
remember updating a credential can be a multi-step action (as I mentioned
before we may for instance want to require password to update OTP, require
verify email to update password, etc). Also, I strongly believe webauthn
will be one of the most important approaches in the future and in that case
we simply can't support a rest api as the keys are tied to the URL.

On Tue, 27 Aug 2019, 11:04 Stian Thorgersen, <sthorger at redhat.com> wrote:

> We've had this discussion many times already, so not sure why this is
> coming up again.
>
> On Thu, 22 Aug 2019, 17:40 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).
>>
>> I disagree - it depends on how it's done. With a SSO solution regardless
> you are using redirects to login so doing redirects for other account
> related activities is expected.
>
>
>>    - 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.
>>
>> Google used this approach a lot. I've also seen it elsewhere.
>
>
>>    - 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.
>>
>> There's very little overhead here. Images and such are already cached.
>
>>
>>    - 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.
>>
>> Required actions is for complex actions that would be costly and time
> consuming to implement in your own apps. Some actions is not possible such
> as webauthn and some actions such as password updates is not wanted as it
> provides access to passwords in clear text to other applications. It also
> opens up for more flexible requirements for some actions such as enter
> password to update OTP. Verify email to update password. Etc.
>
>
>>    - 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.
>>
>
> It benefits implementation as well as custom authenticators. It's not even
> possible to create a rest endpoint for everything such as web authn. It
> would be very complex with custom flows and authenticators to even do a
> custom account app. It increases security. Etc. Etc.
>
>
>> 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.
>>
>