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

[Bill Burke]

On 7/16/2014 9:09 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 16 July, 2014 2:05:15 PM
>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>
>> 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 :-)
>
> Short lived would be covered as there's a timestamp. For single-use we'd have to add the timestamp to the user session or somethin'
>

See my last email.  Just store everything within 
ClientUserSessionAssociationEntity and have a 
ClientUserSessionAssociationEntity per access-code.

class ClientUserSessionAssociationEntity {

    @Id
    String accessCode;

    @ManyToOne
    UserSessionEntity session;

    boolean accessCodeActive;

    long timestamp;

    String clientId;

}




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