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
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.
Raghu
Sent from my iPhone
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
https://lists.jboss.org/mailman/listinfo/keycloak-dev