[Pulp-dev] Pulp 3: using JWT to request a JWT
dkliban at redhat.com
Fri Dec 1 19:41:17 UTC 2017
On Fri, Dec 1, 2017 at 2:30 PM, Brian Bouterse <bbouters at redhat.com> 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
> What about these use case changes to the MVP to reflect this convo?
> On Thu, Nov 30, 2017 at 5:46 PM, Jeremy Audet <jaudet at 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
>> Being secure-by-default, with the option to do useful-but-dangerous
>> things, is a great design approach.
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev