[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keycloak-dev
Subject:    [keycloak-dev] Single-use cache for OAuth code, Code changed to be JWE
From:       mposolda () redhat ! com (Marek Posolda)
Date:       2017-09-29 14:54:30
Message-ID: 171a2041-0fb9-8496-5999-dc240f619082 () redhat ! com
[Download RAW message or body]

I see. The current size of the code parameter is 351 characters. The 
size of the JSON payload itself is 178 characters. The size of the code 
is like:
S + E
where S is 95 (size of the header, AES initialization vector and MAC)
E is size of the encrypted text (approximately payload_size * 1.5)

Fortunately we already have limit for custom notes to be 1000 chars at 
max - 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/request/AuthzEndpointRequestParser.java#L35-L45 \
                
. So I think we should be fine for URL limit of 2000 characters. Still 
we can improve by:

- Use deflate compression - It's supported by JWE specs

- Fallback to have notes in clientSession in case of big code param. 
Then clientSession will be still required in code-to-token endpoint

Marek


On 29/09/17 15:32, Bill Burke wrote:
> Looks good.  Just worry about the size of the code JWT.
> 
> On Fri, Sep 29, 2017 at 7:59 AM, Marek Posolda <mposolda at redhat.com> wrote:
> > I've sent PR https://github.com/keycloak/keycloak/pull/4512, which
> > implements first part of
> > https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit
> >  
> > Some details:
> > - Partially implemented support for JWE, so we can use encrypted JWT.
> > 
> > - OAuth code is changed to be JWT. It's encrypted and
> > integrity-protected with AES128-CBC-HMAC-SHA256 algorithm. Code is
> > encrypted with realm AES key (new symmetric key generated by default for
> > every realm similar to HMAC key) and signed with HMAC key.
> > 
> > - I've added support for AES keys, so we now have RSA, HMAC and AES keys.
> > 
> > - Code JWT doesn't yet contain much at this moment. There is just unique
> > ID, userSession ID, client UUID and expiration (60 seconds). Next step
> > is to add more into it, especially notes as mentioned in the docs.
> > 
> > - Single-use cache is used to track which codes were already used. For
> > now, it's reusing existing "actionTokens" infinispan cache. It's using
> > "putIfAbsent" to add codes into the cache, hence now we are sure that
> > the particular code is really used just once. The previous approach with
> > the note on userSession didn't allow this. I've added new testcase to
> > ConcurrentLoginTest for check that code is used just once. It's passing
> > for cross-dc as well, however we may allow people to save some
> > performance with the small possibility that same code will pass on both
> > datacenters.
> > 
> > - Now we also pass the scenario when SSO login with same client is
> > opened on 2 browser tabs concurrently. Also added test to
> > ConcurrentLoginTest and it's passing for cross-dc too. Previously this
> > scenario may not work correctly as the "code" in the clientSession note
> > may be generated concurrently by both requests and one of them will then
> > fail to verify.
> > 
> > 
> > Next steps:
> > - Continue with the stuff described in the docs
> > https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit
> >  (Remove protocolMappers and roles from clientSession etc).
> > 
> > - It should be easy to use same stuff for refreshTokens . From what I
> > see, the performance of AES128-CBC-HMAC-SHA256 is much better than RSA
> > and provides the encryption too.
> > 
> > Any comments?
> > 
> > Marek
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]