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)?

  • 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 8 '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 8 '14 at 23:05
  • @miraculixx it sounds like you are referring to an API Key rather then user tokens? – DecafCoder Jun 9 '14 at 5: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 9 '14 at 5: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 9 '14 at 7:23
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.