2

I have spent quite a few days reading up on Oauth and token based security measures for REST API's and I am currently looking at implementing an Oauth based authentication approach almost exactly like the one described in this post (OAuth alternative for a 2 party system).

From what I understand, the token is to be verified upon each request to the resource server. This means the resource server would need to retrieve the token from a datastore to verify the clients token. Given this would have to happen upon every request I am concerned about the speed implications of hitting a datastore like MySQL or NoSQL upon every request just to verify the token.

Is this the standard way to verify tokens by having them stored in a RDBMS or NoSQL database and retrieved upon each request? Or is it a suitable solution to have them cached (baring in mind that we are talking millions of users)?

Community
  • 1
DecafCoder
  • 121
  • 2
  • 1
    Why would it need to store the token in a database? Wouldn't it be perfectly acceptable to store it in memory and accepts that if the server crashes or is restarted all tokens become invalid. As sessions don't usually survive a restart why should tokens? – Marjan Venema Jun 08 '14 at 10:27
  • if you assume the token is a hash of a secret, all the server needs to do is hash the secret and if this is equal to the token, the token is valid. No need for database access. – miraculixx Jun 08 '14 at 23:05
  • @miraculixx it sounds like you are referring to an API Key rather then user tokens? – DecafCoder Jun 09 '14 at 05:14
  • @MarjanVenema It's not so much that I want to provide a session for the user, but more of way for the server to know the user making the API call has authenticated. If any abuse of the API occurs then I can also have an idea of what user the abuse is originating from and block the user if need be. I would prefer users not to have to re-login to their mobile applications in the event of a server crash or restart. – DecafCoder Jun 09 '14 at 05:22
  • @DecafCoder the access token should tell the server if the user has been authenticated and granted access to a particular resource, right? Let's say the server issues as the access token T=MD5(X), where X=(referring URL, the source IP address and the day of the year), then every time the user comes back and presents T, the server simply calculates MD5(X`) where X`=(referring URL, source IP and day of the year), and if T==MD5(X`), the token is valid. So there is no need to store anything, in fact storing the access token is a security risk. – miraculixx Jun 09 '14 at 07:23
  • @miraculixx: I am no hashing expert, but wouldn't hashing the (referring URL, source IP and day of the year) limit the validity of the token to a single session on a single day? – Marjan Venema Jun 09 '14 at 11:07
  • @DecafCoder: no re-login after a restart, regardless of the reason, sounds like a security risk? And if that is what you are after then the token becomes more of an API key than an access token. Access tokens by their nature need to have a limited life time? You may also want to check out [security.se]. – Marjan Venema Jun 09 '14 at 11:09
  • @MarjanVenema this was just a simple example to make the point, and yes, you probably don't want to limit to a single day – miraculixx Jun 09 '14 at 13:43

1 Answers1

1

From what I understand, the token is to be verified upon each request to the resource server. This means the resource server would need to retrieve the token from a datastore to verify the clients token. Given this would have to happen upon every request I am concerned about the speed implications of hitting a datastore like MySQL or NoSQL upon every request just to verify the token.

Yes this is true, but you can use an in-memory cache for these tokens if the database is slow for you. Anyways I suggest you to find the bottlenecks with tools instead of making theories.

inf3rno
  • 1,209
  • 10
  • 26