[keycloak-dev] Single-use cache for OAuth code, Code changed to be JWE

[Marek Posolda]

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