[keycloak-dev] Application Initiated Actions

[Stian Thorgersen]

The issue is more around how to authenticate clients and also the fact that
clients wanting to initiate actions may be public clients. We also don't
want to invent a new protocol for this, but rather just rely on the OIDC
flows.

So with those constraints how would you authenticate the client?

On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com> wrote:

> IMO, we should have some level of authorization for clients initiating an
> action. This could be as simple as leveraging authz in order to define
> white/black lists of clients. Similar to what a KC extension does in
> regards to authentication.
>
> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Was hoping for some more feedback from the list on this one.
>>
>> Especially around not having any authentication of the clients wanting to
>> initiate an action. I feel reasonable comfortable about not securing it
>> and
>> requiring actions to prompt the user before doing anything, but welcome
>> others opinion on it.
>>
>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com> wrote:
>>
>> > Since there is no "silent" application initiated action (always
>> > prompts user) possible and actions are predefined at keycloak I see no
>> > need for the client/application restriction mechanism.
>> >
>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <sthorger at redhat.com>
>> > wrote:
>> > >
>> > > Keycloak currently has required actions that are used to prompt the
>> user
>> > to
>> > > perform an action associated with their account after authenticating,
>> but
>> > > prior to being redirected to the application.
>> > >
>> > > Examples include: configure OTP, update profile, validate email, etc.
>> > >
>> > > One issue here is these actions have to be manually registered with
>> the
>> > > users account, but can not be initiated by applications themselves.
>> As an
>> > > example it may not be required by all users to verify their email, but
>> > only
>> > > when they use specific applications.
>> > >
>> > > Keycloak also needs to initiate actions from the account management
>> > > console. Examples: updating email address should require verifying the
>> > > email, configuring OTP, etc.
>> > >
>> > > With that in mind we are proposing to introduce Application Initiated
>> > > Actions. An Application Initiated Action behind the scenes is just a
>> > > Required Action, but it is initiated by an application and depending
>> on
>> > the
>> > > action may be optional for the user to complete (where the user can
>> > select
>> > > cancel which would return the user back to the application).
>> > >
>> > > No Application Initiated Actions should perform any updates to the
>> users
>> > > account without prompting the user first. For example an application
>> > > initiated action that is used to link an existing account to a social
>> > > provider should ask the user first if they want to link to the
>> provider.
>> > >
>> > > To make it easy for applications to integrate these I would like to
>> > > leverage the standard OAuth flows that applications use to
>> authenticate
>> > > users. So to initiate verify-email action the application would
>> redirect
>> > to
>> > > the authentication endpoint and add kc_action=<action alias> query
>> > > parameter.
>> > >
>> > > One open question I have right now is. Assuming all Application
>> Initiated
>> > > Actions always prompt the user first do we need to add some mechanism
>> in
>> > > place to restrict what clients/applications are permitted to initiate
>> an
>> > > action? Requiring that would make it harder to use for applications.
>> > >
>> > > One thing I would also like to add is the ability for an Application
>> > > Initiated Action to require the user to re-authenticate prior to
>> > performing
>> > > the action. For example update password should require the user to
>> enter
>> > > the current password, while verify email should not (as it simply
>> sends
>> > an
>> > > email with a link to continue).
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>