[keycloak-dev] Why access code is in memory

Stian Thorgersen stian at redhat.com
Fri Feb 21 04:07:40 EST 2014

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

More information about the keycloak-dev mailing list