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

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Wednesday, 16 July, 2014 12:42:58 PM Subject: Re: [keycloak-dev] Reset password and verify email links are to long 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(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Bill Burke" >> <bburke(a)redhat.com&gt; >> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>