[keycloak-dev] Action tokens

Tue Mar 28 05:56:17 EDT 2017

On 03/28/2017 09:29 AM, Stian Thorgersen wrote:
> The main idea was to not require action tokens to be one-time, but rather
> invalidate when the users state has changed. That way it doesn't matter if
> user clicks on the link once or twice all links will still work until the
> user changes something. Also, there would be no need to replicate anything
> as it's just leveraging data that is already there. Maybe it's not possible
> with user storage SPI and custom reset password flows though.

I have apparently expressed the one-time support of action tokens in the original e-mail too strongly. What was meant is that action tokens provide means to achieve one-timeness. However the action tokens just by themselves do not guarantee one-time use. If required, it is necessary to implement a single-use check in the operation as outlined in the first thread in this e-mail. E.g. for e-mail verification, this check is not needed, while for password reset it is.

> On 27 March 2017 at 16:38, Bill Burke <bburke at redhat.com> wrote:
>
>> * what if the password isn't stored in Keycloak?  What if the password
>> is stored in an external User Storage Provider?
>>
>
> Can't you get the last update time for the credentials in an external user
> storage provider?
>
>
>>
>> * Each action token type is going to have to maintain this timestamp thing

Only those action tokens that are dedicated for single use - and those anyway need to contain something (be it timestamp, random bytes, ...) that the single-use check has to verify to prevent reuse of the token.

>> * What about verify email or update profile?
>
> Verify email can allow verifying the email as long as the token hasn't
> expired and the email address hasn't changed. It doesn't have to be a
> one-time action.
>
> Update profile would have benefited on having a last updated attribute on
> the user model. Would that screw up user storage provider SPI? If we had
> that the token would be permitted as long as the user hasn't been updated
> since the token was created.
>
>>
>> * reset-password isn't actually reseting the password.  It runs an
>> authentication flow.  This flow could ask for additional information
>> (i.e. "mother's name, birthday, etc.")  It could also reset multiple
>> credential types beyond password.

Absolutely, that's a good point. A reset password action token is actually a permission to start a reset-password flow for the given user. If user storage provider SPI supported last updated attribute on user model (does it?), staring the flow would be allowed only if this attribute on the user (e.g. last updated timestamp) matches the one from the token. If that were not possible, I believe the same behaviour can be achieved by introducing a generic attribute on user model that would change once action token is used and flow finishes. Hence replication would only take place on data change.

>> * aren't you just replacing dependency on one type of replication (user
>> session) with another (database)?

Not replacing, rather removing the need to replicate more data than necessary. Database replication will have to happen on any user change regardless of mechanism allowing that change, and here it is this mechanism that is being improved.

>> * Aren't action tokens supposed to be independent of User sessions anyways?
>> * How can somebody continue with the login flow with an action token?
>> Aren't you still going to have to obtain the user session?

Not have to, and yes, I can make use of it to continue in the session in progress.

> In that case they will open the link in the same browser and the
> authentication session will be there.
>
>
>>
>> I like the idea of action tokens mainly because they can be independent
>> of a User Session.  I just don't think it solves/helps with anything
>> cross-DC related.
>>
>
> It would at least for some things, for example verify email is simple to do
> without any need to replicate anything.
>
>
>>
>>
>> On 3/27/17 8:11 AM, Hynek Mlnarik wrote:
>>> Following up e-mail sent earlier today by Marek, I'm sending info on
>> action tokens.
>>>
>>> Action token is a concept intended as a time-boxed ticket for a bearer
>> to perform a single operation like reset password. They will be used for
>> one-time actions that can be potentially delayed or executed outside of
>> current authentication flow.
>>>
>>> The idea is to implement them as signed JWT tokens where the allowed
>> operation will be specified in token type field. Action tokens will support
>> expiration definable per action (different expiration for e.g. verify
>> e-mail and reset password, or customizable expiration when sent from admin
>> interface). JWT allows both signing and supports custom fields that can be
>> used by the operation to supply additional arguments and to implement
>> prevention of reusing the token once the operation would be performed
>> already.
>>>
>>> Initially it seemed that a distributed cache would be needed to prevent
>> reusing the token for the second time. After thinking it over however it
>> turned out that currently all required cases can be prevented by
>> introducing a field like "last timestamp of the password change" into a
>> reset password token that is checked and operation is only allowed if the
>> token value is equal to the one from database.
>>>
>>> So far the initial implementation covers token in reset-password e-mail.
>> Cache-independent version of action tokens is available here [1].
>>>
>>> --Hynek
>>>
>>> [1] https://github.com/hmlnarik/keycloak/tree/mposolda--cross-
>> dc2-replaced-hmlnariks-commits
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>