Indeed, it seems that HTTP-only and Secure flags on the cookie seems to be
the best solution. However, it seems strange that this is the main workflow
of refresh tokens?
2017-07-03 18:16 GMT+02:00 Alex Berg <chexxor(a)gmail.com>:
Here's my view, FWIW. If the client C is a full OIC client, it
responsible for refreshing. It sounds like you're serving the client, which
is a web app. If it's a web app you're serving, and you are giving the
user's browser a session, then your app server is responsible for
refreshing. I put the access token in an HTTP-only cookie, so I would need
to apply same rules for securing a session token as securing the access
On Jul 3, 2017 9:38 AM, "Antoine Carton" <antoine(a)saagie.com> wrote:
> Suppose a client "C" sends a request with an expired access token, to an
> application "A".
> Suppose that application "A" has the refresh token of client "C"
> "A" automatically uses this refresh token so that everything is
> for client "C" until the refresh token expires as well.
> The trouble is that a leak of the access token (yes, access token) of
> client "C" will have the same result as a leak of the refresh token.
> Is it a good practice to implement automatic refresh of the token? If it's
> not, how should we use the refresh token?
> The Oauth 2.0 RFC (https://tools.ietf.org/html/rfc6819#section-220.127.116.11
> explains that we have to bind the refresh token to the client_id to avoid
> this situation. However, I am not able to understand what it means for
> application "A"?
> keycloak-user mailing list