----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Friday, 21 February, 2014 8:12:33 AM
Subject: Re: [keycloak-dev] Why access code is in memory
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?
Looks like what we'll need to do, unless we store in DB (but that makes expiration a
headache). Sticky sessions probably wouldn't work either as it's not code is given
to the browser, and may be swapped to token by a server-side app on a different IP.
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.
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev