Hi Kamal,
Each client gets their own token and they refresh the tokens independently.
Last session refresh in the user session is the last time any clients in
that user session refreshed the token. It's used to know if a users session
is active or not and we don't care what client it was the user used.
With regards to refresh tokens we need to expire/invalidate the last
refresh for a specific client session within the user session. So we would
need a note on each client session when they refreshed last.
If we did what you proposed it would basically break SSO and only one
client would be able to maintain a working session.
On 13 October 2015 at 02:26, Kamal Jagadevan <j.kamal(a)ymail.com> wrote:
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>
*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>
<mikhail.kuznetsov(a)hpe.com> <mikhail.kuznetsov(a)hpe.com>
*To:* "keycloak-dev(a)lists.jboss.org" <keycloak-dev(a)lists.jboss.org>
<keycloak-dev(a)lists.jboss.org> <keycloak-dev(a)lists.jboss.org>
*Cc:* "Jagadevan, Kamal" <kamalakannan.jagadevan(a)hpe.com>
<kamalakannan.jagadevan(a)hpe.com> <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 <mposolda(a)redhat.com>]
*Sent:* Tuesday, October 06, 2015 1:16 PM
*To:* Raghu Prabhala
*Cc:* Kuznetsov, Mike; <keycloak-dev(a)lists.jboss.org>
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>
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@lists.jboss.org>keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://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