[keycloak-dev] Action tokens

[Marek Posolda]

Ah, yes. Copy-paste would suck on mobile.

It seems that we need to support action-tokens anyway, but I was 
thinking about the "copy-paste" approach as an option, which would admin 
enable if he wants to optimize cross-dc performance and avoid issues 
with spam filters. Hopefully it would be possible to have an 
abstraction, which would allow authenticators to easily use either the 
first or second approach.

But not sure it makes sense as usability on mobiles looks like a blocker...

Marek

On 31/03/17 15:11, Bill Burke wrote:
> 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
>>
>>
>