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 <bbout...@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 <jau...@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@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
