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

[Bill Burke]

On 7/17/2014 11:00 AM, Stian Thorgersen wrote:
> 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
>

Create a ClientAssociation per AccessCode.  As there is a refresh token 
created per access code.  What's great is that you have a log of refresh 
token creation times too.

> 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?!?
>

It is a lot of work, yes.  Changes to a lot of files too.

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