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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 16 July, 2014 2:09:22 PM Subject: Re: [keycloak-dev] Reset password and verify email links are to long On 7/16/2014 8:56 AM, 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? > OH yeah...right. Ugh. Dont you really just need access-code-id and session-id? UserSession stores the rest of the state needed to verify and expire codes, specific to each access-code. Maybe ClientUserSessionAssociationEntity transforms into this access-code storage. Then you could keep track of when a token was created for this client, when access code was created, state of access-code flow, etc.

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