[Pulp-dev] Pulp 3: using JWT to request a JWT

[Brian Bouterse]

I like the ability to refresh tokens. I imagined it would be allowed
forever with no limit (effectively disable JWT_REFRESH_EXPIRATION_DELTA).
If an admin wants to lock out the user they easily can regardless of
renewal. No one suggested this, but I believe we should not expose either
of these options in the Pulp settings at least for now. If we expose this
JWT plugin's feature set to Pulp users, then Pulp will have to carry that
feature set if we ever switch plugins.

Allowing renewal does have an undesirable quality in that you can't issue a
JWT and trust the user has a limited, known amount time on the system. The
other option is to not allow renewal and instead recommend that users who
want longer, or never-expiring tokens can get them like this:
http://docs.pulpproject.org/en/3.0/nightly/integration_guide/rest_api/authentication.html#offline-token-generation

I'm slightly in favor of the "allow endless-renewal from a JWT" approach
because what it lacks in desirable qualities, it ensures that during all
normal usage, the user doesn't have to have to get out a Python shell.

What is the right behavior here?

On Wed, Nov 29, 2017 at 2:57 PM, Jeremy Audet <jaudet at redhat.com> wrote:

> Jeremy, I don't think I understand your comment.
>>
>> You *will* have to use basic auth to refresh the token when the original
>> one expires.
>>
>
> 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.
>
> 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.
>>
>
> If there's security concerns here, then that's important, and they should
> be weighted heavily.
>
> Note that there's an easy-to-use mechanism for invalidating a user's
> tokens.
>
>
>> Refreshing the token with a JWT seems marginally useful to me.
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171129/4cedc1a1/attachment.htm>