browser refresh and back button issues
by Bill Burke
I've been looking into a couple of "browser refresh" bugs. Currently,
if an HTTP request to the auth flow spi did not match the state of the
client session you would
a) have the flow reset if you were currently in the process of
authenticating
b) Show an error screen if you aren't currently authenticating (i.e.
performing required actions)
Now I remember why I did it this way. It is impossible to detect the
difference between a browser refresh and somebody hitting the back
button and resubmitting a previous form. Hitting "browser refresh" will
resubmit any previous form POST. So, you have no idea if the user is
refreshing the current page or resubmitting after a browser back button.
So, I think it is best to keep things the way it is now. Thoughts?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 1 month
Refresh tokens no longer reusable
by Stian Thorgersen
Refresh tokens are no longer reusable. This is done by setting the client
sessions timestamp when a new refresh token is issued. If the refresh
tokens iat value is less than the client sessions timestamp it's not
permitted.
If anyone has time I'd appreciate a review of the changes:
https://github.com/keycloak/keycloak/pull/1732
For anyone that runs into issues with this policy there's an option to
disable it in the admin console in the realms token settings.
This does not apply to offline tokens (at least yet). We need to add it to
offline tokens as well though as it's even more important for those.
There's two problems with offline tokens though, firstly the setTimestamp
is not permitted on offline client sessions. Secondly if we allow setting
it we would have to persist it, unless someone can come up with something
clever.
10 years, 1 month
IDs/names for Mapper Type Properties
by Vaclav Muzikar
Hi all,
I'd like to discuss missing @id and @name attributes on UI elements of
Mapper Type Properties (related issue:
https://issues.jboss.org/browse/KEYCLOAK-1885).
This concerns e.g. creating/editing a Client Protocol Mapper. When you
choose the Mapper Type, the following properties (like "Token Claim Name"
in case of "Hardcoded Claim") don't have any @id or @name.
This properties are used on more places all over the Keycloak (the template
is "kc-provider-config.html" in "keycloak-forms-common-themes" module).
At QE we'd like to add @id for every of these elements so we don't need to
use relative XPath locators based on labels, AngularJS
directives/attributes etc. which could be unstable.
The problem is there's no suitable (object) attribute of these properties
to use as HTML @id or @name.
The closest thing to this is the mapperType.property.name but it's using
illegal characters (spaces) for @id in some cases. E.g. "Claim value" uses
the "claim.value" name which is OK but "Claim JSON Type" uses "Claim JSON
Type" name (yes, the name is same as the label) which can't be used in HTML
as @id because of spaces.
I've got some solutions on my mind.
*1) Replacing the spaces on the client site (using AngularJS
controllers)* which
is probably not a nice solution. The Mapper Types (and it's properties) are
used on more than one sites/controllers and I haven't found any global
getter or something like that for Mapper Types which could contain this
replacement code. As far as I know, Mapper Types are fetched using
ServerInfo service. But this service is pretty abstract and simple so I
don't think it's a good idea to do the replacement there.
That means we need to add some getter and rewrite the controllers to use
this getter or copy-paste the replacement code all over the controllers
which is obviously out of the question.
*2) Add a new ID attribute to the REST API* so the ServerInfo service would
distribute this attribute to all controllers and templates.
*3) Change the "name" attributes* so it can be used as @id. Possible
problem could be compatibility and migration of
current Keycloak installations to the newer version.
Can come upon any other solution? Could you implement any of it?
Thank you!
Best regards,
Václav Muzikář
Keycloak QE
10 years, 1 month
Keycloak doubts
by David Ramírez
Hi guys,
I'm new with Keyloack server, after read the official documentation I have
a couple of questions.
Following the Oauth2 flow:
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
are 'Client' and 'Resource Server' Keycloaks' clients?
For example, I have an Android App and a Service (Java Rest service),
should both be registered in Keycloak Server like clients?
The last question is about Refresh token.
When I'm authenticated for achieving an access token through
'http://localhost:8080/auth/realms/demo/protocol/openid-connect/token',
I received a refresh token too.
If I try to get a protected resource by the refresh token I will get
access to it... Why is it possible? I thought that refresh token was
only for generate new access token. I'm a bit confussed.
I will appreciate any help, thanks.
10 years, 1 month
cancel button added to OTP
by Bill Burke
FYI, I know we removed 'cancel' button from uername password and OTP,
but I brought it back to the OTP page. User wanted ability to cancel
login at OTP page if they decided they didn't want to login with that
account.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 1 month
Offline sessions persistence changes
by Marek Posolda
I've sent PR https://github.com/keycloak/keycloak/pull/1726 with the
persistent changes for offline tokens according to what we discussed
with Stian.
Summary:
- Offline userSessions and clientSessiona are now stored in infinispan,
but also in DB.
- DB storage is done through UserSessionPersisterProvider SPI. I've
added implementations based on JPA and Mongo.
- When new offline userSession and clientSessions needs to be stored, it
is added to both infinispan and persistent storage through
UserSessionPersisterProvider. Revocation/removing of offline session is
also propagated to both infinispan and persister.
- All requests to auth-server (ie. refreshing token etc) interacts with
infinispan storage. Persister is used just during startup to pre-load
infinispan storage with the sessions from DB. This allows that sessions
survive server restart.
- New cache "offlineSessions" was added to the Infinispan. This is
separate to the "sessions" cache as both can have stored sessions with
same IDs, so this is to not clash with each other.
- I've looked at how to best implement the pre-loading of infinispan
with the sessions from persister storage. The infinispan builtin
CacheStore/CacheLoader was my first attempt, however it turned to not
very good for various reasons (For example CacheStore SPI is
incompatible between Infinispan 5 and 6, same for the format of data
etc). In the end I used infinispan DistributionService
http://infinispan.org/docs/5.0.x/user_guide/user_guide.html#_infinispan_d...
. The impl is done in a way that parallel startup of cluster nodes is
not a problem, but an advantage as each cluster node prefills different
sessions. For example if you have 1000.000 userSessions in DB, the node1
will preload around 500.000 sessions and node2 another 500.000 sessions.
If one of the nodes crashes at startup, it's not a problem as well, even
if it's coordinator node. Similarly when new node joins cluster when
other nodes are still starting and pre-loading, new node will
immediatelly start to help with pre-loading. I wonder we can reuse this
stuff for other long-running tasks as well (for example export/import of
big number of users at startup etc)
- MemUserSessionProvider was updated too, so EAP 6.4 in local mode works
fine as well.
- The persister saves offline sessions data into DB partially serialized
into JSON. Just the columns, which are needed for quick DB search (id,
realm_id, user_id, client_id) are saved as DB columns. I think this
should simplify migration and amount of needed work when new field is
added to UserSession / ClientSession.
- It's possible to have more offline sessions / tokens per user+client
Still TODO:
- Add "Offline token idle timeout" . The offline sessions not refreshed
during specified time will be cleared from both infinispan and storage.
Not sure about default value, 7 days?
- Export/import of offline sessions.
- Minor Juca's reported bug: https://issues.jboss.org/browse/KEYCLOAK-1959
- Reduce some INFO logging I've added
- Maybe more if you have additional feedback?
I expect to have it done by Thursday. It seems I will need to postpone
some LDAP enhancements I planned for this release :/
But none of them are critical. Still need to doublecheck export/import
and fix fuse for this release.
Marek
10 years, 1 month
Feature request: Include user (attributes) in FreeMarkerEmailProvider
by Johan Heylen
Hello,
I have a feature request regarding some emails being sent out, like the
password-reset mail. It currently looks like this:
Your administrator has just requested that you update your <realm> account.
Click on the link below to start this process.
<link>
This link will expire within <expiration> minutes.
If you are unaware that your admin has requested this, just ignore this
message and nothing will be changed.
I would like to include the username, and the user full name, and have
already figured out how to do this by updating the messages file and the
*.ftl files in the email theme.
But the list of attributes to be used is limited to what is provide through
the implementation, and I would like to have it include the user as well.
Either a few properties of the user or the full user resource, so I can use
any field of the user.
I know I can fix it by writing a custom module and loading it into my
keycloak, overruling the default provider, with a one-liner:
attributes.put("username", user.getUsername());
or
attributes.put("user", user);
but rather like to see this as the default behaviour, as this would
increase the options of message customisation for everyone
What do you guys think? Worthy of a JIRA ticket?
I can organise a pull request if you need it.
Kind regards,
Johan Heylen
10 years, 1 month
Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token
by Stian Thorgersen
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(a)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(a)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(a)redhat.com<mailto:
> 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> [mailto:
> 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<mailto:keycloak-dev@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(a)lists.jboss.org>
> >> [mailto:keycloak-dev-bounces@lists.jboss.org<mailto:
> keycloak-dev-bounces(a)lists.jboss.org>] *On Behalf Of *Kamal
> >> Jagadevan
> >> *Sent:* Monday, October 12, 2015 8:26 PM
> >> *To:* stian(a)redhat.com<mailto:stian@redhat.com>; Marek Posolda
> >> *Cc:* keycloak-dev(a)lists.jboss.org<mailto:keycloak-dev@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
> >
> >> <mailto:sthorger@redhat.com<mailto:sthorger@redhat.com>>>
> >> *To:* Marek Posolda <mposolda(a)redhat.com<mailto:mposolda@redhat.com>
> <mailto:mposolda@redhat.com<mailto:mposolda@redhat.com>>>
> >> *Cc:* "Jagadevan, Kamal" <kamalakannan.jagadevan(a)hpe.com<mailto:
> kamalakannan.jagadevan(a)hpe.com>
> >> <mailto:kamalakannan.jagadevan@hpe.com<mailto:
> kamalakannan.jagadevan(a)hpe.com>>>;
> >> "keycloak-dev(a)lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
> <mailto:keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org
> >>"
> >> <keycloak-dev(a)lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
> <mailto: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(a)redhat.com<mailto:
> mposolda(a)redhat.com>
> >> <mailto: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(a)redhat.com
> <mailto:mposolda@redhat.com>
> >> <mailto: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(a)hpe.com
> <mailto:mikhail.kuznetsov@hpe.com>>
> >> <mailto:mikhail.kuznetsov@hpe.com<mailto:
> mikhail.kuznetsov(a)hpe.com>>
> >> *To:* "keycloak-dev(a)lists.jboss.org<mailto:
> keycloak-dev(a)lists.jboss.org>"
> >> <mailto:keycloak-dev@lists.jboss.org<mailto:
> keycloak-dev(a)lists.jboss.org>>
> >> <keycloak-dev(a)lists.jboss.org<mailto:
> keycloak-dev(a)lists.jboss.org>>
> >> <mailto:keycloak-dev@lists.jboss.org<mailto:
> keycloak-dev(a)lists.jboss.org>>
> >> *Cc:* "Jagadevan, Kamal"
> >> <kamalakannan.jagadevan(a)hpe.com<mailto:
> kamalakannan.jagadevan(a)hpe.com>>
> >> <mailto:kamalakannan.jagadevan@hpe.com<mailto:
> 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
> <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>
> >> <mailto:keycloak-dev@lists.jboss.org<mailto:
> 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>
> <mailto: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(a)lists.jboss.org<mailto:
> keycloak-dev(a)lists.jboss.org>
> >> <mailto: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(a)lists.jboss.org<mailto:
> keycloak-dev(a)lists.jboss.org>
> >> <mailto:keycloak-dev@lists.jboss.org<mailto:
> 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(a)lists.jboss.org>
> >> <mailto:keycloak-dev@lists.jboss.org<mailto:
> 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(a)lists.jboss.org>
> >> <mailto:keycloak-dev@lists.jboss.org<mailto:
> 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(a)lists.jboss.org>
> >> <mailto:keycloak-dev@lists.jboss.org<mailto:
> 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>
> <mailto: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(a)lists.jboss.org<mailto:keycloak-dev@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<mailto:keycloak-dev@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<mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
10 years, 1 month
Same Refresh token can be used multiple times to obtain access token
by Kuznetsov, Mike
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
10 years, 1 month
