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

Mihai Ibanescu mihai.ibanescu at gmail.com
Wed Nov 29 22:53:21 UTC 2017

To me, the reason to use a token is to grant a client *temporary* access on
behalf of the user who authenticated to begin with.

Perpetual renewal makes the token as powerful as the username+password, and
that seems wrong. Yes, you can invalidate the user's tokens, but it
requires someone to notice that the token got compromised. Time (if an
expiration is set) handles that for you.

Imagine I authenticate with username + password, I get a token, and I use
it a few times. At some point, someone steals the token. If they can renew
it, they will forever impersonate me, until I notice and I request the
token to be invalidated.

If the original token and all its refreshes eventually expire, then they
will have to wait for me to use the system again, in order to either steal
my username + password, or the next token (arguably because if they did it
once, they can do it again). If that won't happen any time soon, my account
will be safe.

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.

SSL will absolutely help and makes it less likely to mess up. But if you
get your token via HTTPS, and somewhere way down into the API there is an
(unsafe) redirect to HTTP that the client blindly obeys and sends the token
(they never should), then your traffic is no longer protected so the token
can be stolen. This scenario sounds like
https://en.wikipedia.org/wiki/HTTP_cookie where browsers know not to send
cookies over non-HTTPS if Secure is set.

Sorry for the long diatribe.

On Wed, Nov 29, 2017 at 4:18 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> 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/95e8d5f9/attachment.htm>

More information about the Pulp-dev mailing list