[keycloak-dev] Same Refresh token can be used multiple times to obtain access token

Wed Oct 7 08:38:47 EDT 2015

You're right, we'd have to introduce a lastRefresh on ClientSession

On 7 October 2015 at 14:35, Marek Posolda <mposolda at redhat.com> wrote:

> On 07/10/15 14:23, Stian Thorgersen wrote:
>
> We should make this configurable. For those worried about security they
> can enforce new refresh tokens as well as offline tokens will replace the
> old tokens. It would be fairly simply to implement. If enabled we would
> only allow refresh token where iat is >= the last session refresh time.
>
> I was also thinking about this possibility. However if you have 2 clients
> and you refresh the token for client1, the refresh token of client2 won't
> be valid as his "iat" will be older. Also SSO login currently refreshes
> lastSessionRefresh on UserSession. However maybe we can introduce
> lastSessionRefresh to ClientSession as well?
>
> Marek
>
> I wouldn't make it default behavior for two reasons:
>
> * It would break existing clients if they expect to continue using the old
> refresh token
> * It comes at a performance cost as clients will have to store the new
> refresh tokens and offline tokens each time they refresh the token
> * For offline tokens Keycloak would also have to persist the last refresh
> time each time the offline token is refreshed
>
> I think we'd need to make it a realm wide configuration option.
>
> On 7 October 2015 at 14:12, Marek Posolda <mposolda at redhat.com> wrote:
>
>> The points are valid and security can be always improved, however
>> sometimes improving security makes things complicated with the not-so-big
>> advantage... IMO admin should always protect the machine to make sure that
>> nobody unauthorized has access to refresh tokens. And for the transport,
>> HTTPS should be always used. But feel free to create JIRA and we will see...
>>
>> When user or client is deleted, all refresh/offline tokens will defacto
>> become invalid as well and can't be used anymore. You're right that offline
>> token is still valid after user logout. User can revoke it manually in
>> account management or admin can revoke it in admin console. However refresh
>> token is invalid after user logout. All refresh/offline tokens for
>> particular client can be revoked by admin by set notBefore policy to now,
>> which can be done in admin console in "Revocation" tab of particular client.
>>
>> Marek
>>
>>
>> On 07/10/15 04:27, Raghuram Prabhala wrote:
>>
>> Very valid points Mike and even I have similar concerns. But please do
>> understand that even if the refresh token is stolen or compromised,it
>> cannot be used by any client unless both the client_id and client_secret
>> are also compromised/stolen. But nevertheless, it is a good practice to
>> assume the worst and add in protective measures to minimize the chances.
>>
>> Marek/Bill/Stian - Even our organization is very particular that such
>> potential security issues be addressed. Can this be taken up? BTW I am not
>> sure if you have an API/End point to invalidate tokens for those that are
>> either compromised or must be invalidated as either the user or client is
>> no longer active. If you do not have one then it is a good idea to make one
>> available.
>>
>> Thanks,
>> Raghu
>>
>> ------------------------------
>> *From:* "Kuznetsov, Mike" <mikhail.kuznetsov at hpe.com>
>> <mikhail.kuznetsov at hpe.com> <mikhail.kuznetsov at hpe.com>
>> *To:* "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
>> <keycloak-dev at lists.jboss.org> <keycloak-dev at lists.jboss.org>
>> *Cc:* "Jagadevan, Kamal" <kamalakannan.jagadevan at hpe.com>
>> <kamalakannan.jagadevan at hpe.com> <kamalakannan.jagadevan at hpe.com>
>> *Sent:* Tuesday, October 6, 2015 4:34 PM
>> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple
>> times to obtain access token
>>
>> Hello,
>>
>> The reason I brought this up is that we are currently working on
>> migrating out authentication from a commercially available product called
>> Ping to Keycloak. We noticed that Ping invalidates the refresh token after
>> it is used once, while Keycloak does not.
>>
>> I and my colleague, Kamal are concerned that by not invalidating the
>> refresh token after first use, we may be opening a security hole. While SSL
>> may protect the token in transit, we can see a scenario where the refresh
>> token would be compromised or stolen from the client itself. In this case,
>> the stolen refresh token could be used to get new access tokens without the
>> owner of the client machine knowing.
>>
>> However, if the behavior was changed so that the refresh token could only
>> be used once, then either:
>> 1.       If the owner of the client machine would use the refresh token
>> first, then the stolen refresh token could not be used
>> 2.       If the stolen refresh token would be used first, then the
>> client machine would not be able to use it and the user of that client
>> machine could be alerted that something was wrong. This user could then
>> reset their password or invalidate all of their access and refresh tokens.
>>
>> Furthermore, we are concerned about this same scenario, but with the
>> offline token. My understanding is that the offline token does not expire
>> and that it can’t be invalidated by logging out the user or changing the
>> user’s password. Have you thought about this scenario?
>>
>> Thank You,
>>
>> *Mikhail Kuznetsov*
>> Software Engineer
>> Hewlett Packard Enterprise
>>
>>
>>
>> *From:* Marek Posolda [mailto:mposolda at redhat.com <mposolda at redhat.com>]
>> *Sent:* Tuesday, October 06, 2015 1:16 PM
>> *To:* Raghu Prabhala
>> *Cc:* Kuznetsov, Mike; <keycloak-dev at lists.jboss.org>
>> keycloak-dev at lists.jboss.org
>> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple
>> times to obtain access token
>>
>> Hi Raghu,
>>
>> >From the specs, it looks to me that this is not anything mandatory. The
>> paragraph is starting "For example". Feel free to create JIRA, but I
>> personally can't promise anything regarding this...
>>
>> Marek
>>
>>
>> On 06/10/15 17:37, Raghu Prabhala wrote:
>>
>> Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token
>> should be invalidated but retained by the server - to handle compromise of
>> refresh tokens as they are long lived.
>>
>> Thanks,
>> Raghu
>>
>> Sent from my iPhone
>>
>> On Oct 6, 2015, at 10:53 AM, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>> You're right, same refresh token can be used more times. However it is
>> still better to use refresh token R2 in your step 3 instead of using old
>> refresh token R1 because R2 has updated timestamp (each token is valid just
>> for 30 minutes or so, depends on the configured SSO session idle timeout).
>>
>> Or are you referring that this is security issue and potential
>> possibility to Man in the middle? If you use HTTPS (which is recommended
>> for production environment, and especially if you have unsecured/untrusted
>> networkl), this shouldn't be an issue.
>>
>> Marek
>>
>> On 06/10/15 16:34, Kuznetsov, Mike wrote:
>>
>> Hello,
>>
>> I noticed that with Keycloak, it seems that refresh tokens are still
>> valid after they are used once. This means that Keycloak does *not*
>> invalidate Refresh Tokens after they have been used once.
>>
>> I am able to successfully execute the following flow:
>> 1.       Obtain Access Token (A1) and Refresh Token (R1)
>> 2.       Use Refresh Token (R1) to obtain new Access Token (A2) and
>> Refresh Token (R2)
>> 3.       Use same Refresh Token (R1) again to obtain new Access Token
>> (A3) and Refresh Token (R3)
>>
>>
>> Can you please tell me if this is the intended functionality?
>>
>> Thank You,
>>
>> *Mikhail Kuznetsov*
>> Software Engineer
>> Hewlett Packard Enterprise
>>
>>
>>
>>
>> _______________________________________________
>>
>> keycloak-dev mailing list
>>
>> keycloak-dev at lists.jboss.org
>>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/0880d932/attachment-0001.html 