[keycloak-dev] Action tokens

[Stian Thorgersen]

I can see the benefits in cross-dc, but I'm not convinced due to the
following disadvantages:

* It would change the current behaviour
* It would need different implementation if the action was triggered by a
user or an admin
* Users would see different behaviour depending on who triggered the action

Personally I don't like the copy/pasting approaches and much prefer simply
clicking on a link.

On 31 March 2017 at 09:17, Marek Posolda <mposolda at redhat.com> wrote:

> I was thinking if we can have the variant of the interactive email
> verification flows ("interactive" means those not triggered by admin,
> but by user himself during authentication process) like this:
>
> - User triggers the flow (For example by click "Forget password" on
> login screen in case of reset-password. Other actions like
> identity-broker linking verification are triggered automatically during
> authentication flow etc)
> - Browser displays "We just sent you an email with the generated code.
> Please type this code here: ". The input field will be displayed too.
> - Email doesn't contain any link. Just the generated code. User needs to
> copy/paste it to the field in the browser and after submit, the flow
> continues.
>
> Advantages:
> - No need to care about spam filters. As no link in the email
> - No need to care if it's same or different browser. Flow will always
> continue in same browser
> - Cross-dc solved. It would be always same browser, so we just need to
> keep the code in authentication session. No action-tokens or any
> cross-dc replication needed
>
> Does it sucks from the usability perspective? For me personally not, as
> when I need to deal with some web-page, which sends me those
> verification emails, I usually just copy/paste the link into the browser
> instead of directly clicking on it (yes, because I don't know in which
> browser it will be opened and I usually want to continue in the same
> browser).
>
> We will still need action-tokens for the admin actions though. For the
> interactive actions, admin will have possibility to choose if he wants
> action-tokens (with link in the email etc) or this optimized flow. I can
> see this can help with spam, cross-dc performance, so IMO makes sense
> for some deployments.
>
> Marek
>
>
> On 28/03/17 15:46, Hynek Mlnarik wrote:
> > On Tue, Mar 28, 2017 at 3:25 PM, Bill Burke <bburke at redhat.com> wrote:
> >> IMO, action tokens should be implemented correctly, as a feature, not
> as an
> >> optimization to support cross-DC.  This means support for one time use
> >> policies, etc.
> > Okay, it seems that support for single use should be implemented as a
> > service and then used by action tokens.
> >
> > So this can be implemented as a cache that would be shared across the
> > cluster / DCs with as little information as possible. Preliminary
> > implementation exists in [1], I'll plug that into current code.
> >
> > [1] https://github.com/keycloak/keycloak/pull/3918
> >
> >> On 3/28/17 5:56 AM, Hynek Mlnarik wrote:
> >>>
> >>>>> * 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?
> >>>
> >>> Not have to, and yes, I can make use of it to continue in the session
> in
> >>> progress.
> >>
> >> I'm saying do you have to/should you verify that the action token
> originated
> >> from a specific session in order to continue the session?  I don't know,
> >> just asking.  These are all things you have to take into account and
> figure
> >> out how to easily hide or provide through the Authentication/Required
> Action
> >> SPI too.
> > I don't think I have to (for instance expiration of the action token
> > to reset password can be e.g. 2 days - much longer than that of a
> > session). But I think that we should support case when the user is in
> > the middle of the flow and is asked to verify their e-mail - here we
> > should continue with the next step in the flow.
> >
> > --Hynek
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>