[keycloak-dev] Reset password and verify email links are to long
Marek Posolda
mposolda at redhat.com
Wed Jul 16 07:42:58 EDT 2014
On 16.7.2014 12:54, 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?
I would personally do it for all to avoid the possibility of exchange
same code for token multiple times.
> * Do we really need session-id and timestamp, or isn't id enough?
I think that session-id is needed to find associated session? As request
for exchanging code to token doesn't have access to browser cookie, so
the info should be associated with the code parameter itself? Maybe
another option is that UserSessionProvider will allow to find associated
session by codeId (something like method on UserSessionProvider like:
UserSessionModel getUserSessionByCode(RealmModel realm, String code);
> * Isn't this pretty much just going back to state-full TokenManager except we're saving it in the UserSession instead of TokenManager itself?
IMO UserSessionProvider has possibilities, which TokenManager didn't
have. Like storing sessions either inMemory or in DB (and hence be
cluster-aware), periodic removal of expired sessions to avoid memory
leaks etc.
Marek
>
> ----- 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 11:34:39 AM
>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>
>> +1 to associate code with the UserSession and remove it once code is
>> exchanged. This will also help to fix the issue we discussed before,
>> that now it's possible to exchange same code multiple times, which is
>> not in line with OAuth2 specs . Created
>> https://issues.jboss.org/browse/KEYCLOAK-560 and linked with
>> https://issues.jboss.org/browse/KEYCLOAK-542
>>
>> Marek
>>
>> On 16.7.2014 10:58, Stian Thorgersen wrote:
>>> Are you talking about reducing the size of the code altogether or just for
>>> the email links?
>>>
>>> I was thinking about just saving the base64 encoded access-code with the
>>> user session temporarily, then sending the the access code id (36 char
>>> uuid as before) in the email. First time the user clicks on the link the
>>> access code would be removed from the session, so this would also make the
>>> links a one-time-click thing.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 15 July, 2014 6:14:45 PM
>>>> Subject: Re: [keycloak-dev] Reset password and verify email links are to
>>>> long
>>>>
>>>>
>>>>
>>>> On 7/15/2014 12:34 PM, Stian Thorgersen wrote:
>>>>>> If that's what you're saying +1.
>>>>> Are you referring to option 1, storing the required info in the user
>>>>> session temporarily? Not sure I understand the details about what you're
>>>>> proposing though.
>>>>>
>>>> Yes, option 1. AccessCode should be associated with the user session.
>>>> Appropriate state needs to be stored in the session as AccessCode
>>>> currently saves a lot of stuff.
>>>>
>>>> Then the code only has to contain:
>>>>
>>>> id, session-id, timestamp
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
More information about the keycloak-dev
mailing list