<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><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><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><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><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></div></div></div>