60

I'm interested in creating API keys for web.api and allowing clients to communicate with API using the API keys rather than authorization web.api provides.

I want multiple clients to be able to communicate with the web.api. instead of creating username and password, can I use an api key, and allow clients to communicate with client.

Is there such built-in functionality?

if one wants to implement it, how would you go around it?

Luke Girvin
  • 13,221
  • 9
  • 64
  • 84
DarthVader
  • 52,984
  • 76
  • 209
  • 300

1 Answers1

73

You are able to achieve by using HMAC Authentication. Basically, there might be a database table called ApiKey (apiKey, secretKey). Each client has each Apikey and secret Key:

  1. ApiKey is like a public key and will be sent over HTTP (similar with username).

  2. Secret Key is not sent over HTTP, use this secret key to do hmac some information and send hashed output to the server. From server side, based on the public key, you can get the relevent secret key and hash information to compare with hash output.

I have posted the detailed answer at: How to secure an ASP.NET Web API

You can change Username by ApiKey and Hashed Password by secret key on my answer to map with your idea.

Community
  • 1
  • 1
cuongle
  • 74,024
  • 28
  • 151
  • 206
  • So you will require the client to build the Hash on every API request? What is the overhead involved here? – EkoostikMartin Aug 06 '12 at 15:41
  • I think so, that's the way which HMAC works, please could you elaborate your questions? – cuongle Aug 06 '12 at 15:47
  • If you will call `ComputeHash(string hashedPassword, string message)` on every method the client calls, how much time does that add to each call? How long does `ComputeHash` take to complete on average? – EkoostikMartin Aug 06 '12 at 15:49
  • has just calculated, around 2600 - 3000 ticks – cuongle Aug 06 '12 at 15:56
  • 1
    Thats nothing, less than a millisecond. So almost no overhead at all, very nice. – EkoostikMartin Aug 06 '12 at 16:01
  • Thanks, we actually applied this approach for our product – cuongle Aug 06 '12 at 16:03
  • @CuongLe "*ApiKey is like a public key and will be sent over HTTP...Secret Key is not sent over HTTP, use this secret key to do hmac some information and send hashed output to server*" - How do you intend to hash using the secret key if it is never sent over the wire to the client? – James Sep 10 '12 at 20:43
  • @James: Secret Key is not sent over each HTTP Request every time, but actually client knows secret key, like you sent an email to client to inform the secret key for them. – cuongle Sep 11 '12 at 02:50
  • So in your scenario "clients" are actually the developers, not users? – James Sep 11 '12 at 11:30
  • @CuongLe "user cannot user api" - depends on what you mean by that. They don't write code to interact with the API, no. However, they are the end users and essentially they will be the ones "using" the API (albeit behind the scenes). Your approach works if you have "developers" writing client apps, however, what if you didn't open it up to 3rd parties? If I had an API and I wanted to write an app which allowed my users to communicate with it I would have to generate a secret key **per user** and send it over the wire to the device to then secure subsequence requests. – James Sep 11 '12 at 11:42
  • Just for the record, I am not disagreeing with your answer as for this particular question it is the right way to go. What I am trying to establish is whether or not it could be tweaked in a way where the secret key is generated on a per user basis. – James Sep 11 '12 at 11:45
  • @James: yes, if you want to use hmac authentication per user, you could create secret key for per user like password. – cuongle Sep 11 '12 at 15:28
  • @CuongLe I guess this takes us back to the original problem - the secret key would have to be sent across the wire. Using SSL would solve this problem though. – James Sep 11 '12 at 18:42
  • @James: Yes, agree, if you can use basic authentication for per user over SSL, would be better. You also can send email to inform secret key for each user, why not? – cuongle Sep 13 '12 at 06:35
  • "*you can also send email to inform secret key for each user, why not?*" - I think this just complicates things, I would prefer if all that stuff happens behind the scenes – James Sep 13 '12 at 08:10
  • 1
    Getting a key to the user has always been a struggle. You could use a 2 step process: have a hashed + salted password sent (along with the salt) over ssl to the service, and have the service send back the associated key. Future transactions use the (hashed + salted) key instead of the password. You could use the password to reset the token as well this way. – Christopher Stevenson Feb 09 '13 at 05:50
  • Is this the same approach that google uses for its API's like the js google maps api? – Zapnologica Aug 30 '16 at 07:38