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 :-)

Marek >>>> * Isn't this pretty much just going back to state-full TokenManager except >>>> we're saving it in the UserSession instead of TokenManager itself? >>>> >>> Yup. :) LOL!!!!! >>> >>> [1] http://tools.ietf.org/html/rfc6749#section-4.1.3 >>> >>> >>> >> -- >> 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 >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev