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

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
> >> To: keycloak-dev at 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.

Yup, I think something like that would be the best way to go. Don't even need session-id in that case, as we should be able to retrieve this based on just the access-code-id.

We'd only need to make sure the access-code-id was safe to use so that it can't be guessed, or as you say slap on a digital signature. 

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