[keycloak-dev] Reset password and verify email links are to long

[Marek Posolda]

On 16.7.2014 15:05, Marek Posolda wrote:
> On 16.7.2014 14:56, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 16 July, 2014 1:47:53 PM
>>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>>
>>>
>>>
>>> On 7/16/2014 8:43 AM, Bill Burke wrote:
>>>> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
>>>>> This is probably what you've said already Bill, but just to make sure:
>>>>>
>>>>> 1. Associate the required information to create a token from an access
>>>>> code with the user session (basically what's in AccessCodeEntry now)
>>>>> 2. The code that is sent as the query param only contains id, session-id,
>>>>> timestamp
>>>>> 3. Once we receive a code to swap for a token we remove the information
>>>>> added in 1 from the user session and use this to generate the token
>>>>>
>>>>> Couple questions:
>>>>>
>>>>> * Do we do this just for emails? or also for the code sent in login
>>>>> redirects?
>>>>> * Do we really need session-id and timestamp, or isn't id enough?
>>>> Actually, do we even need a specific access code?  Even for OAuth 2
>>>> flow?  Just pass around the session id.  All information to validate
>>>> calls, especially accessCodeToToken[1] should be in the UserSession.
>>>> You just have to make absolutely sure you are validating redirect uri
>>>> and client-id to guard against swapping.
>>>>
>>> Actually maybe the access code should be a digitally signed session-id?
>>>     Then you're fully protected from people guessing session-ids.
>>> Granted, the window to guess is relatively short.  *shrug* I don't know. :)
>> It can't just be session-id as there's multiple apps/clients per-session, also even multiple logins for a single app. How about session-id + client-id + timestamp, and we sign it as well?
> Sorry to mention it again, but looks that this is still not enough to
> help with the requirement of "Authorization codes MUST be short lived
> and single-use." of http://tools.ietf.org/html/rfc6749#section-10.5 :-)
Or maybe we can just revoke the request is client with particular 
"client_id" is already associated with this session?

>
> Marek
>>>>> * Isn't this pretty much just going back to state-full TokenManager except
>>>>> we're saving it in the UserSession instead of TokenManager itself?
>>>>>
>>>> Yup. :)  LOL!!!!!
>>>>
>>>> [1] http://tools.ietf.org/html/rfc6749#section-4.1.3
>>>>
>>>>
>>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev