On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse <[email protected]> wrote:
> +1 to using JWT_ALLOW_REFRESH as the name, I read the other name from some > other docs. +1 to adding a refresh token endpoint and some docs. > > We need to update this area in the MVP which is currently in red. We could > replace the use case in red with: "As an API user, I can authenticate any > API call with a JWT" and then add the following two use cases: > > As a JWT authenticated user, I can receive a new JWT if Pulp is configured > with JWT_ALLOW_REFRESH=True > As a Pulp administrator, my Pulp system disallows JWT renewal by default > (JWT_ALLOW_REFRESH=False) > > What about these use case changes to the MVP to reflect this convo? > +1 > > On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet <[email protected]> wrote: > >> 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. >> >> >> Being secure-by-default, with the option to do useful-but-dangerous >> things, is a great design approach. >> > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
