Hi Stian/Marek, Thanks for your attention in the matter.Probably you are referring to one
other issue in client level, but Mike & I are referring at User level within or across
client.
User John Doe authenticates with his credentials and obtains token pair A1R1
- After A1 expires, app refreshes the token pair to A2R2 USING R1
- After A2 expires, app refreshes the token pair to A3R3 USING R1 (ideally it is should
use R2 as it is the latest refresh token)
In order to achieve this functionality, I was wondering why can't we use existing last
refresh time from User session rather then checking it in the client session.IMHO, adding
one more validation in the ValidateToken method in TokenManager class like this should
resolve the problem.
// after userSession is determined either for offline token or online token...
if(oldToken.getIssuedAt() < userSession.getLastSessionRefresh()) {
throw new OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale
refresh token - already used");
}
Please let me know if you see any pitfalls other than the backward compatibility for
existing keycloak users. I can work with you to merge this change & test it in the
master.
BestKamal
From: Stian Thorgersen <sthorger(a)redhat.com>
To: Marek Posolda <mposolda(a)redhat.com>
Cc: "Jagadevan, Kamal" <kamalakannan.jagadevan(a)hpe.com>;
"keycloak-dev(a)lists.jboss.org" <keycloak-dev(a)lists.jboss.org>
Sent: Wednesday, October 7, 2015 8:38 AM
Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain
access token
You're right, we'd have to introduce a lastRefresh on ClientSession
On 7 October 2015 at 14:35, Marek Posolda <mposolda(a)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(a)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(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> 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
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)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