<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 08:53, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAdMVLc6KNKYkVApTBL=nORCgukgZPVxz3DwBn47SDXVbQ@mail.gmail.com"
type="cite">
<div dir="ltr">A small extract from OAuth2 spec:
<div><br>
</div>
<div>
<pre class="" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"> The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token. The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client. If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.</pre>
<pre class="" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">
</pre>
<pre class="" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">Revoking old refresh tokens is optional. With that in mind and the fact that we didn't use to revoke old refresh tokens my vote goes to the default is not to revoke old refresh tokens, but still have the option to enable this for those that want to. I'm going to change it to that.</span></pre>
</div>
</div>
</blockquote>
+1<br>
<br>
Marek<br>
<blockquote
cite="mid:CAJgngAdMVLc6KNKYkVApTBL=nORCgukgZPVxz3DwBn47SDXVbQ@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 15 October 2015 at 08:49, Stian
Thorgersen <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On 15 October
2015 at 08:44, Marek Posolda <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:mposolda@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mposolda@redhat.com">mposolda@redhat.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<div>On 15/10/15 06:36, Stian Thorgersen
wrote:<br>
</div>
<blockquote 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 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>
</span> 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>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Thing is for offline tokens it's even more
important to block old tokens, so would it not make
sense to have it on by default as a security
measure?</div>
<div>
<div class="h5">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> <br>
Marek<br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>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"><a class="moz-txt-link-abbreviated" href="mailto:bburke@redhat.com">bburke@redhat.com</a></a>></span>
wrote:<br>
</span>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"><span><span><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"><a class="moz-txt-link-freetext" href="https://github.com/keycloak/keycloak/pull/1732">https://github.com/keycloak/keycloak/pull/1732</a></a>><a
moz-do-not-send="true"
href="https://github.com/keycloak/keycloak/pull/1732"
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>>><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><span>refreshTokenReusable >
I think we don't need to persist,
but just save clientSession with<span><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></span><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>
</span> its timestamp for idle
checks.refreshTokenReusable <br>
<span> <span><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>
<div>_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
target="_blank">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>
</span></blockquote>
</div>
<br>
</div>
<span> <br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</span></blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</div>
<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>