Re: [keycloak-dev] Why access code is in memory
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