Good approach for a web API token scheme?

Question

Hey folks,

I am working on a REST API for a web application that up until now we have developed internally for a couple of companion applications. Now that we are looking at opening up to outside developers we want to add tokens to the API in order to help identify who is making requests and in general to help manage it's use. At this point we are using https and basic authentication for user authentication on the API.

The token scheme we've been discussing would be very simple where each developer would be assigned 1 or more tokens and these tokens would be passed as a parameter with each request.

My question is if you've done something similar before how did you do it (did you do more or less, how did you handle security, etc) and do you have any recommendations?

Thanks!

Answer 1

First, you might want look at http://OAuth.net. Depending on your usecases, it might provide the security you need.

As to the token, it's a BLOB to most protocols, including OAuth. You can put any information you need in it in any format.

Here is what we do,

1. First we assign each developer a key with associated secret.
2. The token itself is an encrypted name-value pairs. We put things like username, expiry, session id, roles etc in there. It's encrypted with our own secret so no one else can make it.
3. For easy of use with web API, we use the URL-safe version of Base64 so the token is always URL-safe.

Hope that helps!

Answer 2

You might also want to think about maybe adding a time based token that would allow you to limit the amount of time a request is valid. this will help with someone trying to do a replay attack.

You would have a handshake call to get/assign a time valid token based off the above developerKey. This token would be stored locally and passed back to the caller.

The developer would then use this key in a request to validate the request and the developer.

For example that key can then be used for 5 mins or for 10 requests or whatever you define. after that point the generated time based token is removed from the valid list and can no longer be used. the developer will then have to ask for a new token.

Answer 3

UUID is very good for any temporary random key you fancy dishing out. Unpredictable and fast to generate, with collisions so unlikely they are effectively unique. Make nice session keys also.