I think @misa's point is that if a valid token becomes compromised, it could be renewed for a long-maybe-forever time.
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. 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. On Thu, Nov 30, 2017 at 12:21 PM, Jeremy Audet <[email protected]> wrote: > Good points. > > > Another scenario: someone tcpdumps my traffic (yes, somehow they have > the SSL cert, work with this assumption for now). They can come back 3 > days from now, browse the tcpdump output, and renew the token. That would > not be possible with a short-lived token and no renewal past expiration. > > Renewal with expired tokens isn't being proposed. This is a straw man > argument. >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
