+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? On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet <jau...@redhat.com> 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 Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
