<div dir="ltr"><div>I like the ability to refresh tokens. I imagined it would be allowed forever with no limit (effectively disable JWT_REFRESH_EXPIRATION_DELTA). If an admin wants to lock out the user they easily can regardless of renewal. No one suggested this, but I believe we should not expose either of these options in the Pulp settings at least for now. If we expose this JWT plugin's feature set to Pulp users, then Pulp will have to carry that feature set if we ever switch plugins.<br></div><div><br></div><div>Allowing renewal does have an undesirable quality in that you can't issue a JWT and trust the user has a limited, known amount time on the system. The other option is to not allow renewal and instead recommend that users who want longer, or never-expiring tokens can get them like this:  <a href="http://docs.pulpproject.org/en/3.0/nightly/integration_guide/rest_api/authentication.html#offline-token-generation">http://docs.pulpproject.org/en/3.0/nightly/integration_guide/rest_api/authentication.html#offline-token-generation</a></div><div><br></div><div>I'm slightly in favor of the "allow endless-renewal from a JWT" approach because what it lacks in desirable qualities, it ensures that during all normal usage, the user doesn't have to have to get out a Python shell.</div><div><br></div><div>What is the right behavior here?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 29, 2017 at 2:57 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"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Jeremy, I don't think I understand your comment.<div><br></div><div>You *will* have to use basic auth to refresh the token when the original one expires.</div></div></blockquote><div><br></div></span><div>Right. I understand that. I'm not arguing that we allow the user to generate a valid JWT token using an expired, invalid JWT token. I'm arguing that we allow the user to generate a valid JWT token using an unexpired, valid JWT token. This allows use cases such as a client (web browser, CLI tool, etc) being able to re-authenticate itself without re-prompting the user for a username and password. This is especially relevant if the token expiration time is set to a short value, such as 15 minutes.<br></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> So there are limitations to a JWT, and for good reasons. A JWT is a weaker authenticator than a username+password because it expires. Because it is timestamped, it reduces the risk of compromising your account if someone sniffs the traffic.</div></div></blockquote><div><br></div></span><div>If there's security concerns here, then that's important, and they should be weighted heavily.</div><div><br></div><div>Note that there's an easy-to-use mechanism for invalidating a user's tokens.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Refreshing the token with a JWT seems marginally useful to me.</div></div></blockquote></span></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>