6

Note: I fully acknowledge there may be something I'm missing in the picture, which is part of my reason for posting. I'd like to get the opinion of people more experienced than I am on authN/Z related implementations.

Here's where I am stuck on this whole "no refresh tokens on client apps":

The assumption I make is that without a refresh token, we also can't, for user experience reasons, always have a very short-lived access token, i.e. if we had an access token expiring every 15 minutes with no chance of refreshing we'd have to login again every 15 minutes.

My problem: by extending the lifetime of the access token we're giving a potential MIDM attacker a much more dangerous weapon, i.e. a token that gives access to the resources that could last days, or even forever (as I've seen in far too many projects).

To me, the simplest way to resolve such a situation is a refresh token, even one that sits on the front-end, because to my mind that still beats a long lasting ACCESS token.

This refresh token could be:

  • Also a JWT that expires, but maybe expires in a week or so
  • A "use only once" token that gets used to refresh the access token and then gets then replaced by a new refresh token

To my eyes, this approach vs. the long lived access token solves a few problems:

  • with this approach, I get to keep a short lived access token, so if it falls into bad hands it can't be used for long

  • if you think the refresh token is even worse, I disagree, because there's two things that make it better:

    1. once the main user refreshes his token again that previous refresh token won't be usable anymore
    2. if we assume someone steals our refresh token WHILE we're browsing, in a matter of minutes our browser would try to use that refresh token, fail (because someone else used it and so it's no longer usable) and prompt us to login, which will again completely invalidate the other series of refresh token obtained by the malicious entity
    3. even if 1 and 2 weren't true in all scenarios (i'm thinking multiple sessions/refresh tokens allowed so not a single stack or refresh tokens but multiple) i would still wager that you're better off invalidating refresh tokens through whatever procedure you want than you are invalidating access tokens. a JWT access token is valid in itself and the entire purpose of using one is that you can trust it by just verifying it, without having to do other expensive operations like checking with the auth server if it's blacklisted or not. That would essentially mean having to check this sort of thing for EVERY request EVER done with EVERY access token = not very scalable, especially if you compare this to just having to do this sort of thing ONCE every 15 minutes for the refresh token (you could keep a refresh tokens blacklist).

So, with all this said, is having a client side "use once" refresh token that also is a JWT and expires that unreasonable? We're avoiding having the access token last weeks, how can that be bad?

Salvatore
  • 61
  • 1
  • 2
  • why? you can revoke access at any time on the server, for any reason. That's like changing your lock every day; would it make you any safer, or would the enormous hassle lead to a design compromise? If an attacker can somehow get the old token, why can't they get the new one(s)? What threat are you protecting against? – dandavis May 19 '18 at 20:45
  • how though? how do I revoke access anytime? are you suggesting an access tokens blacklist? and should this blacklist check run on every resource request from any other service (e.g. in a microservices context) - my purpose with this approach would be to decouple these necessities (blacklisting/revoking) from the access token which is short lived and have them happen through the much less frequently used refresh token. – Salvatore May 19 '18 at 20:59
  • it seems to me that throug this implicit flow + silent authentication approach I've seen discussed elsewhere (i.e. a self updating access token) we are effectively saying that if we can't have a steel door (which would be having a server app which can keep the refresh token safe) then we should not even bother with a wooden door, a plastic door, but we should keep no door at all because it's all the same. – Salvatore May 19 '18 at 21:01
  • 6 of one, 1/2 dozen of the other. What's the diff between blacklisting and re-authenticating all the time? – dandavis May 19 '18 at 21:11
  • I'm not sure I'm understanding what you mean (and thanks btw for chiming in) - I was talking about blacklisting refresh tokens only in the context of malicious activity discovery. Not re-authenticating all the times would be my purpose, i.e. I want a long session for my users, I don't want them being logged out after 15 minutes of inactivity or every time they close their browser. – Salvatore May 19 '18 at 21:19
  • What I'm trying to say is: - Access token is a JWT, so it should be stateless and the only requirement for its validity would be verifying signature and expiration. Adding further checks on this token would mean making it stateful and would not scale well (checking a blacklist for every resource access request?) – Salvatore May 19 '18 at 21:21
  • - If we want to keep access token short lived and stateless, we can use a refresh token in the implicit flow/silent authentication as well. i.e. in implicit flow/silent authentication the token refreshes itself or doesn't expire (both terrifying for me!), in my approach we're doing the same things, but through two different tokens with more limited powers. I don't understand how this could be considered a bigger vector for attacks, this is the entire point of my question here. – Salvatore May 19 '18 at 21:22
  • @Salvatore I'm sorry but I won't put anything new here. Just wanted to say that I'm asking myself the same question you are for a while already. Everyone on the internet says how bad refresh tokens are bad in the browsers, but this doesn't make any sense as when using it via a HttpOnly, Secure, SameSite cookie makes it pretty secure IMO. Did you maybe get any new insights into this topic? – sarneeh Sep 07 '18 at 09:25
  • 1
    @sarneeh frankly I just gave up discussing with people. Refresh tokens make sense to me, and when I discuss my point of view with people personally they tend to agree. I've certainly kept using them in my projects and will continue to do so. – Salvatore Mar 23 '20 at 00:36

0 Answers0