[keycloak-dev] Same Refresh token can be used multiple times to obtain access token
Stian Thorgersen
sthorger at redhat.com
Wed Oct 14 07:10:50 EDT 2015
I'll try to add it tonight, unless I run into any issues it will be
included in 1.6.
On 14 October 2015 at 11:24, Jain, Rahul (Rahul Jain) <rahul.jain2 at hpe.com>
wrote:
> Could you please tell if this will be done in 1.6 release?
>
>
> Rahul
>
>
> Sent from my LG G3, an AT&T 4G LTE smartphone
>
>
> ------ Original message------
>
> From: Stian Thorgersen
>
> Date: Wed, Oct 14, 2015 12:45 AM
>
> To: Bill Burke;
>
> Cc: Kuznetsov, Mike;keycloak-dev at lists.jboss.org;Jagadevan, Kamal;Jain,
> Rahul (Rahul Jain);
>
> Subject:Re: [keycloak-dev] Same Refresh token can be used multiple times
> to obtain access token
>
>
> 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 at redhat.com<mailto:
> bburke at 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 at lists.jboss.org<mailto:
> keycloak-dev-bounces at lists.jboss.org> [mailto:
> keycloak-dev-bounces at lists.jboss.org<mailto:
> keycloak-dev-bounces at lists.jboss.org>] On Behalf Of Bill Burke
> > Sent: Tuesday, October 13, 2015 3:50 PM
> > To: 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
> >
> > 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>
> >> [mailto: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<mailto:stian at redhat.com>; Marek Posolda
> >> *Cc:* keycloak-dev at lists.jboss.org<mailto: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
> >
> >> <mailto:sthorger at redhat.com<mailto:sthorger at redhat.com>>>
> >> *To:* Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>
> <mailto:mposolda at redhat.com<mailto:mposolda at redhat.com>>>
> >> *Cc:* "Jagadevan, Kamal" <kamalakannan.jagadevan at hpe.com<mailto:
> kamalakannan.jagadevan at hpe.com>
> >> <mailto:kamalakannan.jagadevan at hpe.com<mailto:
> kamalakannan.jagadevan at hpe.com>>>;
> >> "keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> <mailto: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>
> <mailto: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>
> >> <mailto: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>
> >> <mailto: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>>
> >> <mailto: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>"
> >> <mailto: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>>
> >> <mailto: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>>
> >> <mailto: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
> <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>
> >> <mailto: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>
> <mailto: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>
> >> <mailto: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>
> >> <mailto: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>
> >> <mailto: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>
> >> <mailto: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>
> >> <mailto: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>
> <mailto: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
> >>
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > 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
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/5dc93fe6/attachment-0001.html
More information about the keycloak-dev
mailing list