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