[keycloak-dev] Single-use cache for OAuth code, Code changed to be JWE
Marek Posolda
mposolda at redhat.com
Mon Oct 2 06:13:10 EDT 2017
FYI: The remaining work from
https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit
is postponed to 3.4.1.Final for now and maybe further. As it's not an
immediate blocker for cross-dc. Related JIRA is
https://issues.jboss.org/browse/KEYCLOAK-5006 .
Marek
On 29/09/17 16:54, Marek Posolda wrote:
> 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
>>
>>
>
More information about the keycloak-dev
mailing list