[keycloak-dev] Action tokens

[Bill Burke]

* what if the password isn't stored in Keycloak?  What if the password 
is stored in an external User Storage Provider?

* Each action token type is going to have to maintain this timestamp thing

* What about verify email or update profile?

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

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.


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