* 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-hm...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev