[keycloak-dev] Same Refresh token can be used multiple times to obtain access token
Bill Burke
bburke at redhat.com
Tue Oct 13 15:50:01 EDT 2015
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 at lists.jboss.org
> [mailto:keycloak-dev-bounces at lists.jboss.org] *On Behalf Of *Kamal Jagadevan
> *Sent:* Monday, October 12, 2015 8:26 PM
> *To:* stian at redhat.com; Marek Posolda
> *Cc:* keycloak-dev at 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 at redhat.com <mailto:sthorger at redhat.com>>
> *To:* Marek Posolda <mposolda at redhat.com <mailto:mposolda at redhat.com>>
> *Cc:* "Jagadevan, Kamal" <kamalakannan.jagadevan at hpe.com
> <mailto:kamalakannan.jagadevan at hpe.com>>; "keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>" <keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at 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 at redhat.com
> <mailto:mposolda at 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 at redhat.com
> <mailto:mposolda at 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 at hpe.com>
> <mailto:mikhail.kuznetsov at hpe.com>
> *To:* "keycloak-dev at lists.jboss.org"
> <mailto:keycloak-dev at lists.jboss.org>
> <keycloak-dev at lists.jboss.org>
> <mailto:keycloak-dev at lists.jboss.org>
> *Cc:* "Jagadevan, Kamal"
> <kamalakannan.jagadevan at hpe.com>
> <mailto:kamalakannan.jagadevan at 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 at redhat.com]
> *Sent:* Tuesday, October 06, 2015 1:16 PM
> *To:* Raghu Prabhala
> *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at 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 at redhat.com <mailto:mposolda at 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 at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
>
> keycloak-dev mailing list
>
> keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list