I've sent PR https://github.com/keycloak/keycloak/pull/4512, which implements first part of https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9... 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-HVIqO9... (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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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/o... . 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(a)redhat.com&gt; > wrote: >> I've sent PR https://github.com/keycloak/keycloak/pull/4512, which >> implements first part of >> https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9... >> >> >> 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-HVIqO9... >> >> (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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >