0

While reviewing the database for some web sites I noticed tables where OAuth credentials (such as the token, refresh token) among other information are stored on the database.

My understanding is that this information is mainly required for the user session duration and no longer after that, so my question is why would it be kept in a database or stored in any medium?

Could it be stored just to save the cost of re-validation after the session has expired?

schroeder
  • 123,438
  • 55
  • 284
  • 319
NoChance
  • 185
  • 1
  • 9
  • What about the cost of specifically deleting it from the db? Why bother flushing it when it has a limited lifespan? – schroeder Jan 24 '17 at 14:17
  • @schroeder, thank you for your comment. If I understand your point correctly, I think it is useless (and maybe harmful) to persist this information after it has been used once. – NoChance Jan 24 '17 at 14:21
  • My point is, what utility is *gained* by running a function to delete expired tokens? – schroeder Jan 24 '17 at 14:25
  • Well, I know the cost of storing even millions of small rows is not a big deal, but its data no one really wants. A "truncate table" takes a second. I assume that they can't be re-used directly due to short validity period or possible salting process. – NoChance Jan 24 '17 at 14:31
  • 1
    Access Tokens are short-lived, but Refresh Tokens usually have a much longer lifespan. It is possible for a Refresh Token to be used over multiple sessions. (Whether that's safe to do is another matter). – S.L. Barth Jan 24 '17 at 14:33
  • 1
    sometimes the power goes out, should that log the whole fleet out no matter the outage duration? – dandavis Jan 24 '17 at 14:54

1 Answers1

1

There are Access Tokens and Refresh Tokens.

The Access Token is typically short-lived (think 30 or 60 minutes), and there is no reason to persist it after it has expired. It has no use to anyone.

The Refresh Token is required to obtain a new Access Token, and is typically long-lived; at least as long as an active session.

If an attacker gains hold of a Refresh Token, they have all the access that the user would have if they had logged in with that token. However, they have access to session(s) for which that particular Refresh Token authorizes them. (Meaning that, if the token was granted for less than normal privilege for that user, the attacker would be at the same lowered privilege).
Also, since it's not a hashed password, they cannot derive the plaintext password from it with rainbow tables.

A Refresh Token can be retracted at any time, without requiring the user to change their password.

From a security point of view, using a Refresh Token instead of requiring the user to log in again protects against shoulder surfing. The drawback is that if the attacker has physical access to the device that contains the Refresh Token, they don't need to authenticate either.

Be careful when deleting the Refresh Tokens. An expired Refresh Token has no use to anyone, and can be safely deleted. But deleting an active Refresh Token requires users to log in again; causing them unnecessary inconvenience.

Make sure the database containing the active Refresh Tokens is properly secured. They are typically not hashed like passwords are.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
  • Very informative answer. Just one last question please. Is there a reason one can't salt those tokens on the local server? Thanks. – NoChance Jan 24 '17 at 17:07
  • 1
    @NoChance Good question! Using salted hashes of tokens, instead of "plaintext" tokens, seems a good idea to me. I haven't seen this implemented, though. – S.L. Barth Jan 25 '17 at 07:51