The reason for using an API key has been mentioned in this post(What is an API key?) like this :
"Typically, if you can identify the source of a request positively, it
acts as a form of authentication, which can lead to access control.
For example, you can restrict access to certain API actions based on
who's performing the request. For companies which make money from
selling such services, it's also a way of tracking who's using the
thing for billing purposes. Further still, by blocking a key, you can
partially prevent abuse in the case of too-high request volumes."
The above answer is relevant in case of commercial services but what about services like google recaptcha which is a free service? What is the point in having an API key in this case and why do they provide a public and private key?
Valid point. I wish the answer was so that you can see analytics for each of your sites and how many captchas are being displayed, attempted, passed, failed, etc. This would be meaningful information for the website admin. However, I don't believe Google currently provides that information for recaptcha. In this case, I think the answer is so that Google can track that information for their own use, and the reason for the private key might be so people attempting to test programs that break recaptcha must use their own key, making it easier for Google to detect and isolate it, and therefore take measures to change recaptcha to prevent exactly those types of cracks.
Related
My service allow any HTML documents to be converted to PDF using a POST request.
It is mostly used on the backend of my client's server and thus, the API key used for the communication is kept private.
Now, I'm thinking of a way to let my client's visitors be able to call my service on behalf of my client API key, without exposing this secure API Key.
My main issue here is security. If my client add an XHR POST requests that contains the API key, someone can take that API key and use it for their own purpose and abusing my client's account.
I could filter by domain, but this is easily spoofed so it's not possible.
I was wondering if there was a way to call a private service and be identified without risking its identity to be stolen, from the client ('s client) side?
If you're providing this sublet for authenticated users, then it's fairly trivial to give them unique keys (something that hashes their user ID or session against the API key and an initial timestamp, and checks it / logs it / looks for brutes before accessing the API). If you're doing it on the open web, without any kind of user authentication, then rate limiting gets very tricky indeed. Generally you'd want to use a combination of session hashes, IP address, operating system and browser data to create an anonymous profile that gets a temporary key on the frontend. One fairly solid way to do this is to force users through a CAPTCHA before serving a temporary key that allows them a limited number of uses of the permanent key. Any user whose ip/browser/session matches the existing attributes of a known client key is shunted to that one (and gets to skip the CAPTCHA); anyone who doesn't match an existing profile gets the CAPTCHA. That makes you a less attractive target for spoofing. On top of that, you should always rate-limit the entire thing, within a reasonable number of hits per day based on what kind of traffic you expect (or can afford), just so you don't have any surprises. This is the minimal security you'd want if your client's money is on the line every time their API key is used. It will require a simple database to store these "profiles", track usage, check for brutes and maintain the currently valid client keys. Client keys should always be expired regularly - either with a time diff against when they were created, or a regular cron process, or a maximum number of uses, etc.
One other thing I frequently do is rate-limit based on a curve. If I think 5 uses per minute is reasonable, for example, then after 5 uses in a minute from a session, each usage adds a delay of a fraction of a second * the number of uses in the last minute, squared, before the data is served.
The best answer would be to put this all behind a login system and secure that.
Assuming that you are using OAuth kind of system, In that case, make use of Access Token Mechanism that provides access to private API/User's data on behalf of User(Client) without exposing his/her credentials or API Key(Authentication key), also the access token can be expired based on the time/usage.
Example: The access token is generated against a single endpoint that can be the Html Conversion endpoint and will be expired once the action completion.
https://auth0.com/docs/tokens/access-token
And following blog post would be helpful to architect your authentication system
https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
there is no good way to do front-end secure storage but my recommendation is :
is an API that used HMAC signing of requests in combination with OAuth authentication. The API key is actually a signing key. they key does not get transferred. The API key can still get found on the front-end but it becomes useless because you still need the OAuth token to send a valid request.
i know users will have to login in, but you can see this as an advantage because atleast you can log who is using the app by getting information from oauth.
please consider back-end secure storage!
You can use JWT tokens in my opinion. On the basis of username, password or any other info you can generate unique jwt tokens for different users.
Anyone can decipher these jwt tokens but not he unique security token.
If you want to add more more security to tokens, use JWE, encrypted web tokens.
More about these schemes can be found at https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3
Hashing is a decent option and should be done anyway, but for a fully secure method that wouldn't add too much complexity, you could simply abstract away from the authorization/API key by building your own API to interface with the API. This way you could both limit the kinds of things that can be done with the API key and also completely obscure the API key from the user
I don't think you should always go for user auth or JWT, it just doesn't fit all use cases. The idea of using a Captcha is interesting but also somewhat complex.
If complexity is not an issue I would rather use an infrastructure approach, I'm most familiar with AWS so I'll focus on that. Assuming you can change the host of your front end you can have your site hosted on an S3 bucket, served through a CDN, and create a proxy Lambda function that will hold the logic to call your API and store the API key as an encrypted environment variable. This Lambda you call through an API Gateway that can only be called by a specific IAM role which the S3 bucket also uses. You can also use a Cognito User Pool without authentication.
Going back to a simpler alternative the Captcha approach can be implemented as an attestation provider. I know of two services that do this, Firebase and KOR Connect. Due to Firebase using this approach only for their own resources as of the time of this writing I much rather use KOR Connect as it’s a very simple middleware that basically solves this issue. I won't go into detail about these services as it’s not the main concern of this topic but you can check the documentation their respective links.
I am writing an app that uses a 3rd party API service (say Google Maps, segment-analytics etc...). All these apps give an API key that is supposed to be embedded in the JS code.
So anyone who can inspect the source knows the client key. How do these services prevent wrongful usage of that key.
Say someone calls these APIs with my key as many times as the daily allowed maximum API call limit, which will make the further actual API calls fail.
I know that Referrer Header can be used to check the request origin, but Referrer Header can be easily spoofed by a savvy user.
I don't know if there are any measures taken by the services. Seems like a very major problem.
Thanks in advance.
It is a risk, but it's not as bad as it may seem if the API provider is prepared.
The first thing to note is that such an API key is not used for authentication in the sense that it does not authenticate the caller (neither the application nor the enduser). It is only for things like rate limiting and tracking.
So really threats are similar to what you described, for example somebody using your API key and using up your quota. However, if that person is doing that from his own computer or network, all the malicious traffic is seen from his IP or IP range. If the API provider is smart and has good monitoring (like Google), they will not revoke/disable your API key but will filter or disregard the malicious traffic only.
So the attacker should be able to put up a website using your API key and get users to visit it. However, in this case the referer/origin headers cannot be spoofed, browsers won't normally allow Javascript to change the referer or the origin header in the request. So again, the API provider has a way to filter malicious traffic based on referer/origin.
The attacker would need access to many different clients, something like a botnet to make all those requests with your API key to use up your quota. This would probably work, but if an attacker can attack your site with distributed denial of service, your primary concern will probably not be your API keys.
I'm using Teamwork as a project management tool in my team. It is a great tool, but it ridiculously lacks some important functionality. For example, their reporting facility sucks.
Though, they have API using which I can build reports myself. API key is specific to the user, so using any given API key you get access of the owner of the key.
So, if I give my API key, anyones who has it, gets access to all infromation in Teamwork (including information under NDA). So giving my API is not an option.
Making an app where I need to put my API key manually is not an option too, as developer still can get access to this key (by simply recording all inputted keys).
So my question is: is there some way to make authorisation like the one facebook has for other sites for services where such kind of authorisation is not implemented?
I am making a Social Networking website and I want to provide APIs for developers to use. So, I am thinking of using REST API for this.
Now this question is not about how to create a REST API. That is well explained in many websites and SO questions.
My Question is:
When I give a developer this API (lets say which can be used to get user info).
Say USER 1 does not want his date of birth and email to be visible
Say USER 2 does not want his mobile number to be visible
Say USER 3 does not want anyone apart from his friends to see his info
... and so on (each user have their own privacy setting which I have already stored in DB)
Now, how do I authenticate properly to make sure:
1) Developers will not be able to access User info when they have not authenticated the Application to use API to access their info
2) Restrict Developers from accessing fields which has been set by the user as private
Do I have to make separate DBs for this? Is there any easy, professional and secure way to do this?
If you look at the documentation for the various Google+ and FB API's, you'll see what they do. Here's an example:
https://developers.facebook.com/docs/marketing-api/authentication
Generally, you use https to connect, you supply a couple of different key codes (api key, etc.) to an authentication call of some sort, and you get back a session token, which you pass to all subsequent calls that require one (which potentially involve non-public data).
There isn't anything all that special about the authentication that is typically used for this kind of thing, any secure authentication method works as well as any other. All authentication does is establish the identity of the API caller and/or the identity of a user. It is then up to the API code to determine who can access what.
You could have a small group of trusted developers develop the API in a development environment, and then an even smaller group of trusted administrators deploy that API to production servers, and make sure no one else can access those servers except through the API. I believe that's essentially what FB and Twitter and so forth do.
But if you really want to prevent the developers who develop the API and the administrators who set up and maintain your production servers (and databases) from being able to get at user's private data, that data will have to be encrypted on the users' computers, before it is ever sent to the server, using keys that are never sent to the server. So neither the server nor anyone in the server environment will have any way at all to decrypt that data.
But the developers who develop the encryption program that runs on users' computers could make it send keys or decrypted versions of data to a computer somewhere, etc., so there isn't really any way to avoid having to trust at least some of the people involved.
By the way, Google+, Twitter, Facebook, etc., don't do that. They may store some private data in an encrypted form in their production databases, and they may restrict access to those databases to a small group of people, and even those people who have access to the databases may not be able to see the private information without decrypting it - but the data is sent to the servers using https; it is encrypted by a user's browser, but then decrypted on the web server, and it exists in an unencrypted form in the memory of the web server, at least for a short time, so it would certainly be theoretically possible for people at those companies who have the right expertise and the right access to get at users' private data. So our private data on Twitter / FB etc, isn't really 100% secure. (I doubt that any data anywhere is really 100% secure.)
While there are common practices that you can glean from reading their API docs, there aren't really any established standards or best practices that specifically relate to how to code authentication systems for social media APIs in PHP.
It's worth mentioning that many web sites that require user authentication, these days, allow users to authenticate using various external authentication systems, so that once they are signed into one place that uses that system, they're effectively signed into every place that uses it. One really popular external authentication system is GoogleID; for example, users of Stack Overflow can authenticate using their Google logins:
https://developers.google.com/identity/
https://developers.google.com/identity/choose-auth
GoogleID may have been inspired by OpenID. Here is a list of libraries for implementing an API that facilitates OpenID style authentication:
http://openid.net/developers/libraries/
That page includes a couple of php libraries which may be of interest.
By the way, speaking of data security in the context of a social media site, here's an introductory wiki page about the general legal requirements, in the US, for companies that process (potentially) personally identifying information:
https://termsfeed.com/blog/privacy-policies-are-mandatory-by-law/
Call me a newbie, call me dumb, rate down this topic. Do as you like, I'm just here to ask a question and hopefully learn something from it.
So I've been making an API for my website today (well attempting to) and I've noticed this "thing" on most popular sites API's such as Twitter, Foursquare, Tumblr called "OAuth". From my research today I have gathered that it's basically a way of giving the consumer a token to access restricted data from the provider depending on what the user chose without the user handing over their password and username.
But why do I have to use OAuth, why can't I just give out an API to the consumer key and they just use that? I will then see if the user has allowed access for the application, and they will have to grant access for the app to take information from their account, such as photos.
Something that also confused me is why the Tumblr API uses both. It seams on reading blog details they use a simple api key but posting on blogs you need an OAuth Signature.
OAuth is a protocol and has a set of specification defined by some expert group to define how to share data.
Basically what you are seeing is just a part of the OAuth mechanism,and there is a lot of communication and hand shaking mechanism to ensure the security of user data as well avoiding unauthorized access to data.
OAuth mechanism exits at 2 levels
three-legged authentication
Two-legged authentication
Both have their positives and negatives and there are a set of procedure which needs to be taken care for security and data integrity.
Allowing access only based on access_token/consumer key is really a very weak security mechanism and can easily be hacked by any one who happens to get access to your consumer key while OAuth system make sure by sharing a time bound access_token.
For details refer to this thread oauth-2-0-benefits-and-use-cases-why