[keycloak-dev] Application Initiated Actions

[Pedro Igor Silva]

In addition to everything you said.

* It is not only about making changes to account, but updating tokens with
information from required actions, which not necessarily need to be
persisted.

* For back-end applications, we could also associate these required actions
with scopes. If we could have a required action as "Re-authenticate" or
"Provide 2nd factor", that would also help with step-up authentication. As
an alternative to OIDC acr related parameters/claims. I don't think it
makes sense to bring to the client concerns that are really tied to the
scopes of a resource server. As I said, clients should ask for scopes and
Keycloak should do whatever is necessary to grant these (via consent, via
additional steps/actions). Consider what you mentioned at the end of your
design document at "Require Re-Authentication". Couldn't we leverage AIA
for step-up and ask the user for a more stronger credential ?

* Claims gathering flow is simple. The Keycloak server would return the
endpoint to where the client should redirect the user. After obtaining
information from the user, Keycloak would issue a ticket (instead of code).
The endpoint returned by Keycloak would contain the action associated with
a resource. The endpoint could be the same as what you are using for AIA.





On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Pedro,
>
> I really don't understand what your points are and what you propose we do
> here.
>
> The use-case we're addressing is the following:
>
> As a user I would like to initiate an action associated with my account
> through a front-end application so that I can make changes to my account,
> for example to register a WebAuthn security key with my account.
>
> Further, we want an action to be implemented once and re-usable in
> login/registration flows as well as from applications managing user
> accounts, incuding our new account console. That means our new account
> console needs to be able to invoke an action in the login flow, otherwise
> we would have to implement actions as react/rest also.
>
> Now the solution I have proposed is simple. It allows an application to
> request an action being invoked after the user has authenticated. Think of
> it as a "required action" on-demand. It can be implemented with a few lines
> of code and easily tested. It is very easy to use as it just means adding
> an extra query param to the login flows, which makes it very easy to use
> both for confidential and non-confidential clients.
>
> It is not trying to cover claims gathering use-case from UMA. I see no
> connection to this and step-up authentication. These both already have
> clearly defined protocols. Neither can be used to address the above
> use-case.
>
> So please come with a concrete proposal as I have no clue what your
> objections are.
>
> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Is it this stuff you're thinking about:
>>>>>>>>>
>>>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>>>>
>>>>>>>>> From that it does a get including the ticket as a query parameter.
>>>>>>>>> I don't like the idea of sending tickets as query params as they could be
>>>>>>>>> logged. For the application initiated action it would have to be an ID
>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>>>>>>>> creating a ticket that can only be used to initiate an action.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why you need to send the id token if the client already got an id
>>>>>>>> token and, considering browser flow, there is a cookie that can be used by
>>>>>>>> Keycloak to identify the client/user ?
>>>>>>>>
>>>>>>>
>>>>>>> Cookie doesn't authenticate the client, only the user.
>>>>>>>
>>>>>>
>>>>>> But the identity cookie has the user session and from it we can check
>>>>>> whether or not the client initiating the action (client_id) has a
>>>>>> authenticated client session, no ?
>>>>>>
>>>>>
>>>>> That only proves that the client_id belongs to a client that has
>>>>> obtained a token. It doesn't authenticate the client in any way.
>>>>>
>>>>> Q- Why is authentication of the client required? IMO it is not
>>>>> required.
>>>>>
>>>>
>>>> Sure, but the client obtained token and is authenticated, thus acting
>>>> on behalf of the user. If the client is already acting on behalf of a user,
>>>> we don't need to authenticate it.
>>>>
>>>
>>> That's not correct. All we know is that a client with the same client_id
>>> has obtained a token. Anyone can use the same client_id to initiate an
>>> action.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Perhaps what we could do is:
>>>>>>>>>
>>>>>>>>> 1. By default any application can initiate an action
>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
>>>>>>>>> sort, just a regular oauth flow
>>>>>>>>> 2. Later add support if demand to limit what applications can
>>>>>>>>> initiate actions
>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>>>>>>>>> everyone then no need for a ticket
>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>>>>> applications we would need some form of authentication.
>>>>>>>>>
>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>>>>
>>>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>>>>> redirect does
>>>>>>>>> b. Add support to obtain an initiate action ticket from a endpoint
>>>>>>>>> using an id token as bearer token
>>>>>>>>> c. Add a note into client session with a initiate action ticket
>>>>>>>>> for clients that can initiate actions and map this into the id token.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not sure ...
>>>>>>>>
>>>>>>>> If you think about it, the part interested in obtaining the claims
>>>>>>>> after an action is completed is not the client but the audience of the
>>>>>>>> token, the resource server. In this case, the UMA approach seems more
>>>>>>>> appropriate because the resource server is in control about what actions
>>>>>>>> the client should initiate in order to fulfill the constraints imposed by
>>>>>>>> the resource server to access its protected resources. Where these
>>>>>>>> constraints could be a DOB in the token or a higher security level.
>>>>>>>>
>>>>>>>> The app initiating actions in the server is not the goal, but the
>>>>>>>> tool to obtain additional claims from the server ...
>>>>>>>>
>>>>>>>> However, for some applications acting as both client and resource
>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>>>>>> redirect the user to the server as you pointed out in 1.
>>>>>>>>
>>>>>>>
>>>>>>> Perhaps there's a case for that, but that would be claims gathering,
>>>>>>> not application initiated actions.
>>>>>>>
>>>>>>> Application initiated actions are more a tool for folks to add
>>>>>>> actions for the user account into their own GUIs, and as such should be a
>>>>>>> simple protocol. OAuth incremental scopes for example doesn't have any
>>>>>>> flows between app and service, but rather just allows the app to get the
>>>>>>> scopes it out of bounds knows it needs for specific actions.
>>>>>>>
>>>>>>
>>>>>> I think claims gathering and AIA are pretty much the same thing. Both
>>>>>> are querying the user for additional information. Despite if you are
>>>>>> initiating an action to request user's DOB or update a password, they are
>>>>>> steps that the user must perform in order to enrich its security context
>>>>>> and be able to continue using both client and resource server.
>>>>>>
>>>>>> The point I'm trying to make is that AIA can solve other problems
>>>>>> too. You would still solve the original problem from your design document
>>>>>> as defined in the motivation section. While you would also help with
>>>>>> step-up authentication and UMA claims gathering. Another point is related
>>>>>> to the party interested in the action. Is it the client or the resource
>>>>>> server (the API)?
>>>>>>
>>>>>
>>>>>>
>>>>>
>>>>>> If the client (which honestly I don't see much use as most apps seem
>>>>>> to be a combination of front-end + back-end, where the functionality is
>>>>>> provided by the back-end and protected by a bearer token) then you may just
>>>>>> consider passing the "kc_action" parameter and have the action initiated.
>>>>>>
>>>>>> If the resource server, you could associate the required actions with
>>>>>> the scopes. So when a client requests a specific scope, Keycloak will start
>>>>>> the action(s) and query the user for some information prior to issuing the
>>>>>> access token.
>>>>>>
>>>>>> Still, if the resource server, the resource server could respond to
>>>>>> the client (e.g: UMA flow) indicating that it needs more info, then the
>>>>>> client will just redirect the user to the location provided in the response
>>>>>> to initiate the actions.
>>>>>>
>>>>>
>>>>> I don't understand what your point is or what you are proposing here.
>>>>>
>>>>
>>>> And I do understand your point of view. I just think that it can do
>>>> much more than address new account management console requirements.
>>>>
>>>> Based on your design document, I understand what you described in the
>>>> Motivation section. But again, instead of considering the "two things" that
>>>> originated the idea behind AIA, I think we can take the opportunity and do
>>>> much more. As they seem related to me. Especially after your DOB example.
>>>>
>>>
>>> I don't see the additional use-cases you are mentioning as related at
>>> all.
>>>
>>
>> How it is not related ? The audience of the information gathered during
>> the AIA does impact where the token with the information will be used. If I
>> need a DOB to access some page in my front-end, this is one thing. If I
>> need DOB to access some resource protected by a resource server it is
>> another thing. Both require tokens with different audiences, the former
>> will probably be an ID Token where the latter the access token.
>>
>> In OAuth2 the scopes represent the permissions to access protected
>> resources. Thus, it does make sense to have required actions that can
>> challenge a user when requesting scopes. Considering your DOB example, if
>> my client wants to access resource /api/age/check why you want the client
>> to request kc_action=dob if the scope "dob" is what he needs to access the
>> API ? Otherwise, you are making the client aware of things that are really
>> related to the resource server. It is OK the client ask for scope "age", it
>> is how OAuth2 authorization model works.
>>
>> UMA leverages OAuth2 in a way that the permission ticket makes the client
>> really dumb about what it needs to access protected resources. With UMA,
>> the client will just receive a ticket and with that ticket it can perform
>> the necessary actions to make a successful authorization request to the
>> server.
>>
>>
>>>
>>> * Step-up authentication has already clear parameters in OIDC/OAuth to
>>> request high level of authentication. On the implementation side it's about
>>> invoking additional parts of the authentication flow, not to initiate an
>>> required action that has nothing to do with the authentication flow.
>>>
>>
>> Can we consider a required action as a prompt for 2nd factor, for
>> instance ?
>>
>>
>>>
>>> * Claims gathering in UMA is about asking the user for additional
>>> claims. AIA can be used as a poor-mans workaround to lack of claims
>>> gathering, but end of the day it's completely different. AIA will allow an
>>> app to invoke the action update_DOB, while claims gaterhing will allow the
>>> application to request the claim DOB.
>>>
>>
>> Not sure, if the difference is due to updating a piece of info, both
>> flows request the user for the info. Is just a matter of updating or not
>> updating the info.
>>
>>
>>>
>>> I don't see what additional things we need to consider for something
>>> that is in the end very simple and can be implemented in a couple hours
>>> including tests if we don't try to make it more complicated.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why do you think authentication/authorization is required?
>>>>>>>>>>>>>> The user will be prompted before making an action and it's an action they
>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The client is making the request and even though the user is
>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>>>>>> some level of authorization.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You could even consider not authenticating the client at all,
>>>>>>>>>>>>> but still allow admins to enforce which clients should be allowed to
>>>>>>>>>>>>> initiate actions on the server.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>>>>>>> actions will work without authenticating the client.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>>>>>> redirecting the user.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>>>>>>>> redirect_uris are already being checked. It's just a standard OAuth flow.
>>>>>>>>>>
>>>>>>>>>> IMO that's fine as long as there's no need to limit what clients
>>>>>>>>>> can initiate actions. If that's needed then we need something more
>>>>>>>>>> complicated that properly authenticates the client, as anyone could just
>>>>>>>>>> use the client_id and redirect_uri from a different application to get the
>>>>>>>>>> action initiated (although wouldn't then have the user redirected back to
>>>>>>>>>> the app of course).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can
>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different client.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what happens
>>>>>>>>>>>>> after the user performs an action. Is he/her redirected back to the client
>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that the client is
>>>>>>>>>>>>> known and that the user will be redirected back to a valid URI.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens.
>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>>>>>> the DOB being available in the token.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This flow seems very closely related with the Claims Gathering
>>>>>>>>>>> Flow from UMA specs. We could probably review what is there and see if it
>>>>>>>>>>> can help to solve this problem of app initiated actions.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Go for it ;)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint where
>>>>>>>>>>>>>> the application can request a token to initate an action. So flow would be:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would return a single use
>>>>>>>>>>>>>> token.
>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>>>>>>>>>>>>>> instead of "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function that
>>>>>>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not sure what you mean about 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>