<div dir="ltr">Your proposal is basically what we have today (except it’s called JWT_ALLOW_REFRESH in django-rest-framework-jwt rather than JWT_REFRESH). You can configure settings for django-rest-framework-jwt from the server.yaml file [0] so users can turn on/off JWT_ALLOW_REFRESH. It defaults to False.<div><br></div><div>The only thing we need to add is a refresh token endpoint (see [0]) and some docs.<div><br></div><div>[0] <a href="https://getblimp.github.io/django-rest-framework-jwt/#additional-settings">https://getblimp.github.io/django-rest-framework-jwt/#additional-settings</a></div><div>[1] <a href="https://getblimp.github.io/django-rest-framework-jwt/#refresh-token">https://getblimp.github.io/django-rest-framework-jwt/#refresh-token</a></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Nov 30, 2017 at 2:14 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@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"><div>I think @misa's point is that if a valid token becomes compromised, it could be renewed for a long-maybe-forever time.<br></div><div><br></div><div>I'm reading a desire to have Pulp exhibit both of these types of behaviors, and both for good reasons. What if we introduce a setting JWT_REFRESH. If enabled, JWT_REFRESH will allow you to receive a new JWT when authenticating with an existing JWT. Defaults to False.</div><div><br></div><div>I'm picking False as the default on the idea that not renewing tokens would be a more secure system by limiting access in more case than when JWT_REFRESH is True. In the implementation, when JWT_REFRESH is set to True it would fully disable the JWT_REFRESH_EXPIRATION_DELTA setting so that it could be refreshed indefinitly. The user would never know about JWT_REFRESH_EXPIRATION_DELTA.</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 30, 2017 at 12:21 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@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">Good points.<span><br><br>> Another scenario: someone tcpdumps my traffic (yes, somehow they 
have the SSL cert, work with this assumption for now). They can come 
back <span class="m_2814891232253591694m_-8408933826843752292gmail-aBn"><span class="m_2814891232253591694m_-8408933826843752292gmail-aQJ">3 days from now</span></span>,
 browse the tcpdump output, and renew the token. That would not be 
possible with a short-lived token and no renewal past expiration.<div><br></div></span><div>Renewal with expired tokens isn't being proposed. This is a straw man argument.<br></div></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>