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

[Marek Posolda]

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