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

[Bill Burke]

On 7/16/2014 8:56 AM, 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?
>

OH yeah...right.  Ugh.

Dont you really just need access-code-id and session-id?  UserSession 
stores the rest of the state needed to verify and expire codes, specific 
to each access-code.  Maybe ClientUserSessionAssociationEntity 
transforms into this access-code storage.  Then you could keep track of 
when a token was created for this client, when access code was created, 
state of access-code flow, etc.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com