<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 15/10/15 06:36, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAeGtKDrsNBi+vSADapepJOCtTD=r+neDSipimAVu4ePZw@mail.gmail.com"
type="cite">
<div dir="ltr">That was my initial idea as well, but then again it
already works with our adapters, we already regenerate the
tokens, so why not add this extra layer of defence? End of the
day as refresh tokens can be stored on the client side how well
they are secured can vary. If users want long sessions or even
worse with offline tokens it makes sense to add this that
enables users to at least notice something is going wrong. The
issue is that you may not notice that a client has been
compromised, but if all tokens stop working you will.</div>
</blockquote>
<blockquote
cite="mid:CAJgngAeGtKDrsNBi+vSADapepJOCtTD=r+neDSipimAVu4ePZw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>I don't have an issue with setting it to true by default
(so refresh tokens are reusable), but since our adapters
already work and I can't see any big side effects of
preventing refresh token reuse I set it to false by default.</div>
</div>
</blockquote>
As I said, I can see the side effect just for offline tokens, that
people will always need to write new offline token into their DB on
application side after each refresh.<br>
<br>
Marek<br>
<blockquote
cite="mid:CAJgngAeGtKDrsNBi+vSADapepJOCtTD=r+neDSipimAVu4ePZw@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 15 October 2015 at 01:27, Bill Burke
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=""><br>
<br>
On 10/14/2015 5:49 PM, Marek Posolda wrote:<br>
> On 14/10/15 20:24, Stian Thorgersen wrote:<br>
>> Refresh tokens are no longer reusable. This is
done by setting the<br>
>> client sessions timestamp when a new refresh
token is issued. If the<br>
>> refresh tokens iat value is less than the client
sessions timestamp<br>
>> it's not permitted.<br>
>><br>
>> If anyone has time I'd appreciate a review of the
changes:<br>
</span>>> <<a moz-do-not-send="true"
href="https://github.com/keycloak/keycloak/pull/1732"
rel="noreferrer" target="_blank">https://github.com/keycloak/keycloak/pull/1732</a>><a
moz-do-not-send="true"
href="https://github.com/keycloak/keycloak/pull/1732"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="https://github.com/keycloak/keycloak/pull/1732">https://github.com/keycloak/keycloak/pull/1732</a></a><br>
<span class="">>><br>
>> For anyone that runs into issues with this policy
there's an option to<br>
>> disable it in the admin console in the realms
token settings.<br>
>><br>
>> This does not apply to offline tokens (at least
yet). We need to add<br>
>> it to offline tokens as well though as it's even
more important for<br>
>> those. There's two problems with offline tokens
though, firstly the<br>
>> setTimestamp is not permitted on offline client
sessions. Secondly if<br>
>> we allow setting it we would have to persist it,
unless someone can<br>
>> come up with something clever.</span><br>
<span class="">refreshTokenReusable > I think we don't
need to persist, but just save clientSession with<br>
> updated timestamp into infinispan/memory. Then during
startup, the<br>
> timestamp of clientSessions will be updated to
startup time similarly<br>
> like we have for lastSessionRefresh of user sessions.
The refresh will<br>
> be allowed if (iat == clientSession.timestamp OR
startupTime ==<br>
> clientSession.timestamp) . In other words, first
refresh after server<br>
> restart will be always allowed.<br>
><br>
> There is some chance that there can be same refresh
token used two<br>
> times (if attacker will do second refresh after
server restart). But<br>
> then clientSession timestamp will be updated and
regular user won't be<br>
> allowed to refresh his token and will recognize
error.<br>
><br>
><br>
> But question is, do we really want
refreshTokenReusable to be disabled<br>
> by default? For offline tokens, people will often
need to save the<br>
> offline token into their database on application
side. With<br>
> refreshTokenReusable disabled, they will need to
always write into their<br>
> DB and save new offline token after each refresh.<br>
><br>
<br>
</span>My own personal opinion is that we are making this
fix to pass some<br>
random company's security audit that I don't particularly
agree with.<br>
If a client has been compromised, then its offline tokens
should be<br>
revoked and a revocation not-before policy should be pushed
out. As it<br>
is, the only reason we need to regenerate the refresh token
is to update<br>
its timestamp for idle checks.refreshTokenReusable <br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a moz-do-not-send="true"
href="http://bill.burkecentral.com" rel="noreferrer"
target="_blank">http://bill.burkecentral.com</a><br>
</font></span>
<div class="HOEnZb">
<div class="h5">_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>