4:34 p.m.
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
4:53 p.m.
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
5:37 p.m.
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
7:16 p.m.
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
>> 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
10:34 p.m.
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@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:27 a.m.
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
#yiv9982859949 #yiv9982859949 -- _filtered #yiv9982859949
{font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv9982859949 {panose-1:2
4 5 3 5 4 6 3 2 4;} _filtered #yiv9982859949 {font-family:Calibri;panose-1:2 15 5 2 2 2 4
3 2 4;} _filtered #yiv9982859949 {font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2
4;}#yiv9982859949 #yiv9982859949 p.yiv9982859949MsoNormal, #yiv9982859949
li.yiv9982859949MsoNormal, #yiv9982859949 div.yiv9982859949MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;color:black;}#yiv9982859949 a:link,
#yiv9982859949 span.yiv9982859949MsoHyperlink
{color:#0563C1;text-decoration:underline;}#yiv9982859949 a:visited, #yiv9982859949
span.yiv9982859949MsoHyperlinkFollowed
{color:#954F72;text-decoration:underline;}#yiv9982859949 pre
{margin:0in;margin-bottom:.0001pt;font-size:10.0pt;color:black;}#yiv9982859949
p.yiv9982859949MsoListParagraph, #yiv9982859949 li.yiv9982859949MsoListParagraph,
#yiv9982859949 div.yiv9982859949MsoListParagraph
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0pt;color:black;}#yiv9982859949
span.yiv9982859949EmailStyle18 {color:windowtext;}#yiv9982859949
span.yiv9982859949EmailStyle19 {color:#1F497D;}#yiv9982859949
span.yiv9982859949HTMLPreformattedChar {font-family:Consolas;color:black;}#yiv9982859949
span.yiv9982859949EmailStyle22 {color:#1F497D;}#yiv9982859949 .yiv9982859949MsoChpDefault
{font-size:10.0pt;} _filtered #yiv9982859949 {margin:1.0in 1.0in 1.0in
1.0in;}#yiv9982859949 div.yiv9982859949WordSection1 {}#yiv9982859949 _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {font-family:Wingdings;} _filtered
#yiv9982859949 {font-family:Symbol;} _filtered #yiv9982859949 {} _filtered #yiv9982859949
{font-family:Wingdings;} _filtered #yiv9982859949 {font-family:Symbol;} _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {font-family:Wingdings;} _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered
#yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered
#yiv9982859949 {}#yiv9982859949 ol {margin-bottom:0in;}#yiv9982859949 ul
{margin-bottom:0in;}#yiv9982859949 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 doesnot 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
2:12 p.m.
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
2:23 p.m.
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 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>
*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>
*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
*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
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
2:35 p.m.
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
2:38 p.m.
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
>
2:26 a.m.
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
6:42 a.m.
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
9:03 p.m.
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(a)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@redhat.com<mailto:sthorger@redhat.com>>
To: Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com>>
Cc: "Jagadevan, Kamal"
<kamalakannan.jagadevan@hpe.com<mailto:kamalakannan.jagadevan@hpe.com>>;
"keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>"
<keycloak-dev@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@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@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@hpe.com><mailto:mikhail.kuznetsov@hpe.com>
To: "keycloak-dev@lists.jboss.org"<mailto:keycloak-dev@lists.jboss.org>
<keycloak-dev@lists.jboss.org><mailto:keycloak-dev@lists.jboss.org>
Cc: "Jagadevan, Kamal"
<kamalakannan.jagadevan@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@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@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:50 p.m.
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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:56 p.m.
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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:53 a.m.
If your application is careless with refresh tokens, there's not much
Keycloak can do other than session management and revocation policies.
Refresh tokens are not supposed to be distributed or shared.
But, I've scheduled a jira for this. It may get done 1.6, 1.7 at the
latest.
On 10/13/2015 4:56 PM, Kuznetsov, Mike wrote:
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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:45 a.m.
We've already discussed how to implement this. We'll add a lastRefresh for
a client session and only permit refresh/offline tokens if the iat time is
=> lastRefresh for the client session. Simple to implement. However, our
current adapters do not update the refresh tokens they use so this would
have to be updated as well. Also, it could potentially break existing
functionality. So we should probably make it a configurable option for a
realm under token settings and have it disabled by default initially. In a
future release we could then enable it by default for new installations.
On 14 October 2015 at 01:53, Bill Burke <bburke(a)redhat.com> wrote:
If your application is careless with refresh tokens, there's not
much
Keycloak can do other than session management and revocation policies.
Refresh tokens are not supposed to be distributed or shared.
But, I've scheduled a jira for this. It may get done 1.6, 1.7 at the
latest.
On 10/13/2015 4:56 PM, Kuznetsov, Mike wrote:
> 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(a)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
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3124
days inactive
3132
days old
16 comments
7 participants
participants (7)
-
Bill Burke -
Kamal Jagadevan -
Kuznetsov, Mike -
Marek Posolda -
Raghu Prabhala -
Raghuram Prabhala
-
Stian Thorgersen