Jump to content

Keeping API authentication keys private on client


NotionCommotion

Recommended Posts

I have the following workflow.

  1. Web client logs on to web server and sets session cookie.
  2. Web client makes request to web server, and is allowed access by checking session.
  3. Responding to the request, web server makes a request to a different server utilizing cURL, and includes a secret API authentication key in the header.
  4. Other server makes sure the secret authentication key is valid, and responds with some data to the web server.
  5. Web server sends that data to the web client.

Instead of having the web sever proxy the data from the other server to the web client, is it possible to have the web client directly request data from the other server without exposing the secret API authentication key?

 

I was first thinking that the web client could make an initial request to the web server to receive a random value plus the secret authentication key encrypted with that random value, store both in a cookie, and send both to the other server which would unencrypt the key and return the data.  But then I realized this does nothing.

 

Any thoughts how this can be accomplished?

Link to comment
Share on other sites

Who controls the outermost server? Why can't you have one API key per client?

 

And who are the clients? Human users? If so, what kind of users? Arbitrary people on the Internet? A small group of experts? Or are you talking about automated clients? If so, where are they installed?

Edited by Jacques1
Link to comment
Share on other sites

Who controls the outermost server? Why can't you have one API key per client?

 

And who are the clients? Human users? If so, what kind of users? Arbitrary people on the Internet? A small group of experts? Or are you talking about automated clients? If so, where are they installed?

 

The web servers are Drupal websites.  They also act, however, as clients when they access the other server via cURL, and each Drupal website has its own API key.

 

The clients I was referring to are browser clients operated by any person accessing the Drupal websites.

 

Does this make sense?  Also, what do you mean by "the outermost server"?

 

Thanks

Link to comment
Share on other sites

The only way to keep the API key secret is to have the server proxy the requests as you described. Even if you try and get fancy and encrypt the token on the client so that one can't just view-source to grab it, they can always just intercept the request and extract the key that way.

 

Aside from that, the Same-origin rule would prevent you from using external API's generally, unless the API supports Cross-origin resource sharing which is not typical I think.

Link to comment
Share on other sites

The only way to keep the API key secret is to have the server proxy the requests as you described. Even if you try and get fancy and encrypt the token on the client so that one can't just view-source to grab it, they can always just intercept the request and extract the key that way.

 

Aside from that, the Same-origin rule would prevent you from using external API's generally, unless the API supports Cross-origin resource sharing which is not typical I think.

 

I think external APIs generally work.  Take google maps for instance.

 

In regards to keeping the key secret, maybe based on a limited time after client authenticates with webserver and limit to clients IP?  Yes, I know client IP can be spoofed, but one would have to know when it was accessed.

 

That being said, I don't think I need to get fancy, and will just proxy it (however, for curiosities sake, still would like to know if it could be done).

 

Also, maybe an advantage to proxy is the web server could cache the API.

Link to comment
Share on other sites

I think external APIs generally work.  Take google maps for instance.

Generally APIs work either (a) server-side with something like cURL or (b) client-side by using an external Javascript library which does the API calls and thus obeys the same-origin rule. If you were supposed to write your own Javascript code to interact directly with the Maps APIs then Google would have to set up CORS to allow that.

 

Proxying is probably the best solution. Any reason you're trying to stop doing that?

Link to comment
Share on other sites

If you were supposed to write your own Javascript code to interact directly with the Maps APIs then Google would have to set up CORS to allow that.

Ah, that makes sense.

 

 

Proxying is probably the best solution. Any reason you're trying to stop doing that?

I had a notion it might allow the server client better performance, but wasn't that serious about it, and was more curious whether such a technique was possible.

Link to comment
Share on other sites

(however, for curiosities sake, still would like to know if it could be done).

 

In theory, yes:

  • You could use the session ID as a tempory API key; the API server would validate the session ID through an interface on the Drupal site (which simply yields a valid/invalid reply).
  • The Drupal site could issue a client-side API session which is protected with a message authentication code or cryptographic signature.
  • Maybe OpenID or OAuth work as well.
  • Public-key authentication (e. g. TLS with client certificates) is another theoretical option.

In practice, not really.

Edited by Jacques1
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.