[keycloak-dev] Why access code is in memory
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?
> 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.
JBoss, a division of Red Hat
More information about the keycloak-dev