[keycloak-dev] Action tokens
bburke at redhat.com
Tue Mar 28 09:13:04 EDT 2017
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
> session) with another (database)?
> * Aren't action tokens supposed to be independent of User sessions
> * 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
> 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.
More information about the keycloak-dev