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

----- 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 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(a)redhat.com&gt; >>> To: keycloak-dev(a)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'