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(a)hpe.com>
*To:* "keycloak-dev(a)lists.jboss.org" <keycloak-dev(a)lists.jboss.org>
*Cc:* "Jagadevan, Kamal" <kamalakannan.jagadevan(a)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@redhat.com]
*Sent:* Tuesday, October 06, 2015 1:16 PM
*To:* Raghu Prabhala
*Cc:* Kuznetsov, Mike; keycloak-dev(a)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(a)redhat.com
<mailto:mposolda@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(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev