[keycloak-dev] Action tokens

[Bill Burke]

On 3/28/17 3: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.
>
> On 27 March 2017 at 16:38, Bill Burke <bburke at redhat.com 
> <mailto: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?
Maybe.  Maybe not.  Who knows?  We won't.

>
>     * Each action token type is going to have to maintain this
>     timestamp thing
>
>     * 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.
Some storage providers are either read-only or can only write a specific 
set of attributes.

FYI: We already store user consent and account links no matter which 
provider is providing user info.

>
>     * 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.
>
>     * aren't you just replacing dependency on one type of replication
>     (user
>     session) with another (database)?
>
>     * 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?
>
>
> In that case they will open the link in the same browser and the 
> authentication session will be there.

You still need some sort of session for reset-credential flow.

>
>     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.
We have custom required actions.  The SPI will now have to provide 
metadata on whether the action requires the update timestamp or not.

Bill