1

I understand the need for oauth for programmatic access to apis, etc. whereas passwords are used for more human-level authentication. However when we store passwords, we (hopefully) salt + hash them. When we store tokens they are in some format that can be reversed into plaintext as we often surface these tokens to developers.

What I find curious is that I have not come across any concern for storing tokens, but isn't this inherently less secure treatment than that for passwords? Why are we okay with this? Couldn't we hash the token in the db after the one time we show it to the developer and then if they need to change it ask them to reset (just like we do for passwords)?

Improve this question
2

2 Answers 2

Reset to default
1

Tokens and passwords are really very different things. But you haven't specified in your question what you are really asking. You mention OAuth in the subject line of your question but then don't mention it again in the body of the question. OAuth has different kinds of tokens in its spec, depending on what sub-spec you're talking about and what kind of token you're talking about.

I have to assume you're talking about Bearer tokens, i.e, the tokens that are handed out after the OAuth flow is completed. In some cases you may not even need to store Bearer tokens in the server anywhere, so the question of whether or not to store them as hashes doesn't apply. If you're talking about refresh tokens, then that might be a situation in which you might want to store them, but I can also see the same methods applied to refresh tokens as to bearer access tokens, so they probably don't need to be stored on the server either, they just need to be signed to detect tampering. In order to get OAuth to work this way, you'd need to take a look at the OAUTH-JWT Bearer token spec: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bearer-12

That all having been said, no matter what kind of token you are using or what kind of OAuth flow you're using, you should be relying on TLS to secure the communication between resources.

OAuth is a very complex spec and there is no one-size-fits-all answer to most of the questions about OAuth.

Improve this answer
2
  • Why the down vote? The question asked in very generic terms about OAuth and tokens. I don't think an answer needs to go into details about OAuth and its complex flows. I'd like someone to explain what sort of details the answer should contain to avoid down votes.
    – RibaldEddie
    Commented Jan 31, 2016 at 1:48
  • I know this question was originally asked a while ago, so I apologize it's taken so long to get back to it. The perspective I was asking from was that of an oauth provider, who fundamentally must store tokens. What I was confused by was the fact that so many providers show developers those tokens indicating that they're not hashed when stored by the provider. I was asking if that makes the whole system weaker than passwords as passwords if hashed/salted properly would be much more difficult to recover
    – winhowes
    Commented Apr 26, 2016 at 11:27
1

You seem to be confusing authentication with authorisation. OAuth is chiefly about authorisation and has various flows to support different scenarios and use cases, one in particular which overlaps with your question supports user / resource owner password based authentication for authorising the requesting application access to some set of resources.

As others have pointed out in their answer there are many different flows within OAuth and different kinds of tokens, and various token specifications for use with OAuth. In many systems a token will be a random value or a cryptographically signed payload so the server can avoid storing anything. Tokens are vastly different to user passwords and are used for different use cases, ie conveying authorisation.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .