[keycloak-dev] Application Initiated Actions

[Pedro Igor Silva]

One way is to follow authorization code constraints like checking the
client_id and redirect_uri (assuming the user will be redirected back after
the action completes). But still, we could also add some level
authorization.

On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> 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
>>>
>>