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

[Stian Thorgersen]

Just started on this. Quick summary of my attack plan:

1. Remove AccessToken from AccessCode. Instead add List<String> rolesRequested and create AccessToken in TokenService.accessCodeToToken. Any reasons why this wouldn't work?
2. Move some info from AccessCode to UserSession, and remove anything redundant. For example username used to login, auth-method (social or form), remember-me.
3. Add info from AccessCode to UserSessionProvider and send signed key instead as the code query param.

With regards to the required info here's what I've come up with:

To verify the code:

* Need to know it hasn't been done before - can either be done by having a timestamp on ClientAssociation that is incremented every time a code is requested/used, or by having a ClientAssociation per-code. As we'll need to store more specific to a code than just the fact it has been used or not, I think it's best to just have a ClientAssociation per-code
* Not expired - no prob
* Session active - no prob
* redirect_uri when retrieving code matches redirect_uri query param when swapping for token - we don't do this currently I think, but spec requires it. This would require a ClientAssociation per-code.
* Correct client_id - no prob, just make sure code belongs to the client_id query param

Then to create the token we need:

* List of roles requested - the union of user roles and app/client scope. This would require a ClientAssociation per-code as the role-mappings/scope could change between user granted the roles to the client and the code is exchanged. Also in the future once we add a scope query param this will be required.
* Realm - no prob, user-session is associated with a realm
* Client - no prob, ClientAssociation is associated with a client
* User - no prob, user-session is associated with a user
* Session - no prob, user-session is a session ;)

All in all it seems like a bit more work than I initially considered. Or am I attacking this completely wrong?!?


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 2:14:45 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> 
> 
> On 7/16/2014 9:09 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: keycloak-dev at 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 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?
> >> 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'
> >
> 
> See my last email.  Just store everything within
> ClientUserSessionAssociationEntity and have a
> ClientUserSessionAssociationEntity per access-code.
> 
> class ClientUserSessionAssociationEntity {
> 
>     @Id
>     String accessCode;
> 
>     @ManyToOne
>     UserSessionEntity session;
> 
>     boolean accessCodeActive;
> 
>     long timestamp;
> 
>     String clientId;
> 
> }
> 
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>