[keycloak-dev] Why access code is in memory

Bill Burke bburke at redhat.com
Fri Feb 21 08:30:48 EST 2014


OpenID Connect say you SHOULD:

"An Attacker attempts to use a one-time use token such as an 
Authorization Code that has already been used once with the intended 
Resource. To mitigate this threat, the token SHOULD include a timestamp 
and a short validity lifetime. The Relying Party then checks the 
timestamp and lifetime values to ensure that the token is currently valid.

Alternatively, the server MAY record the state of the use of the token 
and check the status for each request."


I don't want to use Infinispan, at least as a distributed cache. 
Because then you have to secure that communication as well and it might 
be a headache in Openshift deployments.

On 2/21/2014 3:12 AM, Marek Posolda wrote:
> ah yes, there is this in OAuth2 specs section 4.1.2:
>
> If an authorization code is used more than
>           once, the authorization server MUST deny the request and SHOULD
>           revoke (when possible) all tokens previously issued based on
>           that authorization code.
>
>
> I wonder if Infinispan is the way to go? This will address both
> clustering (replication) and memory leak (expiration). Or you want to
> avoid this?
>
> Marek
>
>
> On 20.2.2014 21:34, Bill Burke wrote:
>> I remember one of the reasons access code is in memory.  When a code is
>> turned into a token, the code is removed.  Thus, the code can only be
>> used once and only once to obtain an access token.  This can be
>> mitigated of course by timeouts on the access code.
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-dev mailing list