[keycloak-user] Workflow Refresh token

[Antoine Carton]

Hello Alex,

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?

Thanks!

2017-07-03 18:16 GMT+02:00 Alex Berg <chexxor at gmail.com>:

> Here's my view, FWIW. If the client C is a full OIC client, it should be
> 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
> token.
>
> On Jul 3, 2017 9:38 AM, "Antoine Carton" <antoine at saagie.com> wrote:
>
>> Hello,
>>
>> 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" and that
>> "A" automatically uses this refresh token so that everything is
>> transparent
>> 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-5.2.2.2)
>> 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"?
>>
>> Thanks!
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>