I implemented it this way initially with the Auth SPI rewrite and was
vetoed.
Personally I dont like the link because it opens up a new browser tab or
window. Plus with the code approach there's no way an attacker can
spoof the url and send people rogue emails. But, the link approach is
better if I'm on a mobile device.
On 3/31/17 3:17 AM, Marek Posolda 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(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