[keycloak-dev] Action tokens

[Bill Burke]

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 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
>
>