Hello Bill,
It is my understanding that revoking the session will log out the user, so I'm not
sure that it will address the problem. I think what we want is to revoke a specific
refresh token after we use it once so that it cannot be used again.
I'm also not sure how we would use a not-before policy, since we would need to update
this policy every time we get a new access token / refresh token pair.
Thank You,
Mikhail Kuznetsov
Software Engineer
Hewlett Packard Enterprise
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Bill Burke
Sent: Tuesday, October 13, 2015 3:50 PM
To: keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access
token
tokens are associated with sessions. Log out the user's sessions, and the tokens are
now invalid. You can also push out a a not-before revocation policy. Applications will
deny any tokens issued prior to the not-before timestamp. All this is doable in the admin
console.
There is an issue though with bearer-only REST services and access tokens. They do not
get notified of logout events as they are stateless and instead rely on expiration of the
access token (which is why access tokens should be short lived). You'd have to rely
on pushing out a not-before revocation policy.
IMO, because you can logout users and/or push out a revocation policy, I really don't
see this as a high priority security issue for 1.6. I'll see if I can get it in
before Friday.
On 10/13/2015 3:03 PM, Kuznetsov, Mike wrote:
Hello,
As advised earlier, I have put a JIRA ticket for this issue:
https://issues.jboss.org/browse/KEYCLOAK-1961
We are excited to start using Keycloak to support our product, but
right now we are blocked due to this issue because it has been flagged
by our security team when they were reviewing our design.
Over the past few days, we have tried to overcome this issue by trying
to revoke either the specific access token / refresh token if it is
used more than once, or trying to revoke all the tokens for the user.
However, we were unable to find a mechanism that would let us do this.
*Do you know if there is any mechanism to revoke a specific token, or
to revoke all tokens for a user? Are there any plans to implement this
in the future?*
**
Thank You,
*Mikhail Kuznetsov*
Software Engineer
Hewlett Packard Enterprise
*From:*keycloak-dev-bounces@lists.jboss.org
[mailto:keycloak-dev-bounces@lists.jboss.org] *On Behalf Of *Kamal
Jagadevan
*Sent:* Monday, October 12, 2015 8:26 PM
*To:* stian(a)redhat.com; Marek Posolda
*Cc:* keycloak-dev(a)lists.jboss.org; Jagadevan, Kamal
*Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple
times to obtain access token
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*
1. After A1 expires, app refreshes the token pair to *A2R2 *USING R1
2. 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.
Best
Kamal
----------------------------------------------------------------------
--
*From:*Stian Thorgersen <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>>
*To:* Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
*Cc:* "Jagadevan, Kamal" <kamalakannan.jagadevan(a)hpe.com
<mailto:kamalakannan.jagadevan@hpe.com>>;
"keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>"
<keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@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
<mailto:mposolda@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
<mailto:mposolda@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>
<mailto:mikhail.kuznetsov@hpe.com>
*To:* "keycloak-dev(a)lists.jboss.org"
<mailto:keycloak-dev@lists.jboss.org>
<keycloak-dev(a)lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org>
*Cc:* "Jagadevan, Kamal"
<kamalakannan.jagadevan(a)hpe.com>
<mailto:kamalakannan.jagadevan@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
<mailto:keycloak-dev@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
<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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org