[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