I have created an API and I would like to allow other developers to get the information from it. So the idea is to generate and assign API keys to everyone that wants to query our information. With API keys I can limit the daily requests and secure my data.
The thing is, I am concerned about the security aspect of it. Since the API key is going to be sent to our server (via GET/POST etc)?
I am looking for the best solution to handle this problem.
The solution in my mind is to use Asymmetric Cryptography to handle this.
Is it the right way to handle this? If not what is the best way.
Any help will be highly appreciated.
Related
I was working on a project, and needed to make an API call to my website https://dashboard.lawliet.host/api/setcoins, it took in a header Authorization, which was the admin API key.
I obviously don't want the API key exposed to the user if they check the outgoing requests, or deobfuscate the program. What is a good and easy solution to get around this?
What I did think of what to hash the API key in this program, and compare it with the key in my server. According to me, this will work, but I do want to know if there's a better/easier way to accomplish it.
P.S: English is not my first language, so if anyone could edit this question and fix any grammatical errors, I would appreciate it.
Thanks,
MisuteriasuKe
I am currently working on a Rest-API using Golang. That API includes authentication so I manage to save the sessions id in a map. Everything is working very well, but now am wondering if I should save the sessions id in the database. I am thinking in things like security, memory usage, performance and standars used in the industry.
So which is the best approach to make it? Thank you very much
If you are making a RESTful API as you are, consider using authentication bearer tokens instead. You may wish to consider using JSON Web Tokens for that. A RESTful service wants to have as little (preferably none) server side state as possible.
As this is a Go question, a good library for using JWT and JWE is go-jose from Square.
Is it possible to use Mailchimp API to subscribe emails to the lists of MY USERS' Mailchimp Accounts and not my own?
Basically I have a web app, and users collect emails of various subscribers through this app. I then want them to be able to click a button and subscribe all those emails to their lists.
I've looked at Mailchimp's API - particularly the /lists/subscribe and the /lists/batch-subscribe methods. However so far it appears that these will only work for your own Mailchimp account and not for remote users' accounts.
Can someone please tell me whether what I'm trying to achieve is possible with Mailchimp's API?
You would need to execute the api-calls with your users' api-key, which would mean that you execute the calls with their credentials.
There are three different ways to get their api keys, with different practicality levels.
You guess. They look like guids without dashes, and some information about which datacenter it is associated with. Some easy (and somewhat bad) calculations indicate that there are 2^128 api keys in every datacenter, so this will consume both cpu- and network-resources, and invoke the rage of the Mailchimp. The linked image shows him on a good day. He won't be as pleasant if you choose this alternative. Dont do this.
You ask, in an evil way, for their username/password. This is bad since it will give you to all accounts those credentials works with. This would also give you access to stuff that aren't available using api calls (like payment stuff). This wont work at all if your user is intelligent administrators that are using AlterEgo, the two-factory security alternative. This alternative is less bad than blindly guessing, but still provides too much access, if it works at all.
You ask, in a user-friendly way (with perhaps some quick tutorials), for the user to generate an api-key in mailchimp to provide to you. This is the Good Alternative (tm).
You may choose any implementation as long as you choose number three.
I really don't understand this OAuth authentication method, so I just gave up. The reason I decided to create my own was because I believe the functions my API will carry out aren't that big, it'll mostly be able to read data and occasionally write too.
Here's my plan for API requests on my site.
Consumer API Request with a special key > User Authorise's Application (if not done so already) > Callback URL to consumer upon authorising > Run API Script on provider > return result to consumer.
Is this okay? This is my first time writing an API for any site, so I'm here to learn.
In general, I would say that if you're trying to roll your own authentication protocol because you don't understand the existing ones, you're making a Fatal Mistake™.
The only time you should consider doing this is if you totally understand the protocol in question, and require some functionality from it that you are 100% sure it does not offer. OAuth is complicated because it has to be. Certain requirements exist to make sure it's secure.
In writing your own without understanding the complexity, you're setting yourself up to fail.
I'm going to try to phrase this as a generic question.
A company runs a website that has a lot of valuable information on it. This information is queried from an internal private database. So technically, the information in the database is the valuable part.
If this company wished to develop an API that developers could use to access their database of valuable & useful information, what approach should the company take?
It's important to give developers what they need. But it is also important to keep competing websites from essentially using the API to steal everything and essentially steal all traffic from the company's website.
Is there was some way the API could be used in a way that drives traffic back to the original company's website somehow? Something that gives users a reason to keep going there.
This is a design consideration that my company is struggling with that I can imagine other web-based services have come across before.
Institute API keys - don't make it public. Maybe make the signup process more complex than "anyone with an e-mail address".
Rate limit the API based on keys. If you're running more than X requests a minute, you're likely mining the database.
Don't provide a "fetch everything" API. Make the users know something to get information on it. Don't reveal what you know.
I've seen a lot of companies giving out API keys and stating a TOS that all developers must adhere to. For example, any page that uses data from the API must include your logo and a link back to your website. If any developer is found breaking the rules, the API key can be cancelled and your data is safe again.
Who is meant to use the API?
A good general method of solving this problem is to limit access to the data to end users (rather than allow applications or developers at it). Provide applications and users with identification, each, and make sure that to access a subset of the data, a combination of both user and application key is required.
Following this pattern, each user will have access to a very limited subset of the data (presumably, the data that they require for their own specific use), and you can put measures in place to enforce this. Any attempts at data-mining will become obvious.
This type of approach meshes well with capability-type security models on the server side.