[keycloak-dev] Access code length

Tue Jul 29 11:20:56 EDT 2014

Access code work completed.

UserSessionProvider now has a ClientSessionModel that represents a clients access to a users sessions. This contains all the details that used to be in the access code itself, with the exception of what was already moved to UserSessionModel.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 10:53:58 AM
> Subject: Re: [keycloak-dev] Access code length
> 
> Thanks for suggestions.
> 
> Now the code looks like:
> 
>   xuAZKwa2EkX_WBHp-LPHXXQYKc0.YjUzMmRhODAtZTFkZS00MTZjLTk1ZjktNGJlMGYxMDNmNGE2LTE0MDY2Mjc0NDg4NjE
> 
> This consists of two parts (both Base64 url-encoded):
> 
>   <Hashed Signature>.<ID>
> 
> The hashed signature is the SHA-1 digest of the SHA256withRSA signature of ID
> + timestamp + action
> 
> To verify a code the details for the AccessCode is retrieved using the first
> part of the code. Then the hashed signature is created from the stored
> details and compared to the first part of the code.
> 
> This provides both brute force protection, and also protects against UUID
> collisions (which should be very unlikely, but still).
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Monday, 28 July, 2014 7:48:34 PM
> > Subject: Re: [keycloak-dev] Access code length
> > 
> > Smaller hash (sha1 or md5) is really the only thing you can do beyond
> > removing the JWS header.  But, if you're going to do that, might as well
> > just ditch the signature altogether.  If anything, over time, we'd be
> > using larger hashes not smaller ones.
> > 
> > HMAC is smaller, but that would require a realm secret key.
> > 
> > With a HMAC header and computing the JWS of:
> > 
> >          String uuid = UUID.randomUUID().toString();
> > 
> > 
> > 156 chars for HMAC 512 secret key
> > 113 chars for HMAC 256 key
> > 99 chars for HMAC SHA1 (We'd have to implement SHA1 which would be easy
> > to add)
> > 
> > 
> > Header is 20+ characters.  uuid is 36 chars.
> > 
> > My bet is that Google is using HMAC + SHA-1
> > 
> > 
> > 
> > 
> > 
> > On 7/28/2014 12:59 PM, Marek Posolda wrote:
> > > Something, which comes to my mind:
> > >
> > > * Omit the header part with algorithm info and instead assume that code
> > > is always signed with rsa-256 (or whatever different algorithm)
> > >
> > > * Is it really needed to have System.currentTimeMillis() info here? I
> > > wonder if this timestamp info can be extracted to server side as well,
> > > so when code is later looked-up, you will also have info about the time
> > > when it was created without the need of pass this info as part of the
> > > code
> > >
> > > * It seems that the biggest part (around 170 characters) is signature. I
> > > wonder that it can be reduced by either:
> > > ** Use not so strong algorithm to sign the code (not sure if it's
> > > security issue as code is one time usage though and it's better than
> > > avoid signature at all...)
> > > ** Actually it's keycloak itself, which verifies signature. So I wonder
> > > if instead of passing the whole signature around, it can just pass the
> > > hash of signature (just few characters). Then later during verification
> > > phase, it has access to whole accessCode content, so it can sign the
> > > content again and compute again the hash of signature and compare it
> > > with the hash passed from code parameter.
> > >
> > > Marek
> > >
> > > On 28.7.2014 18:14, Stian Thorgersen wrote:
> > >> I've made the changes to access code, but I'm still not happy with the
> > >> length.
> > >>
> > >> The old access code containing all the details (including access token
> > >> and
> > >> id token) was at least 1000 characters long (with more roles and id
> > >> token
> > >> details that would have been even bigger!).
> > >>
> > >> The new access code length is 259 characters. I think this is still to
> > >> big
> > >> and would like to reduce it. The way I'm currently creating it is taking
> > >> the ID (UUID.randomUUID() + System.currentTimeMillis()) and using
> > >> JWSBuilder to add a signature. Example:
> > >>
> > >>     eyJhbGciOiJSUzI1NiJ9.MTVhMjFiNWMtNjcxYy00YzYyLWEyOGMtNmFmMzE4YzE0NjkzMTQwNjU2MzMwNzQyMw.djN2v1Egz1Fime-2bVvYyv529KNMChYh3e0rY5UU4TImv53ppwNhrmWaZRNzO0xLULRC8IeixrH6K3nR1cMyHZb9Ef8Vr46YvNmE8Q_qac821GAWMNzEKjYcXt87AhSSz8BY54CcbKIPLfxFC8smI-KDA1Mr5SrJ_Ch-zdLDbdM
> > >>
> > >> I checked Google it's just:
> > >>
> > >>     4/YJcHpG7-DcoVcwNH_8D-NDQKcP_Y.MijWXLPgpOwToiIBeO6P2m9c72_7jgI
> > >>
> > >> Suggestions welcome ;)
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 