2:17 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev