I assume it's a bad idea to give away your Secret API Key. I have a freelancer making a script that accesses Coinspot's API, and he has asked for it.
I'd appreciate anyone's advice on the topic.
Related
I'm using web api for my application on ASP.NET CORE
If someone see application soruce code, there is a backend url, isn't it?
Then, that guy can use my api if he succeed my application decompile
How protect that situation
I'm just stutdent, so... Just my curiosity
Authenticate your API
If you plan on having a private API (not open to everyone), then you should force users to authenticate themselves by using an API access token. Each token should be specific to a particular user, and there should be consequences for distributing a private key (such as revoking it and blocking the person associated with it) or else people will just share them without care. This will allow users to communicate with your server and run commands or queries as they please. Assuming you have written these functions correctly, they shouldn't allow an attacker to access much beyond his given scope of given API functions (which should be queries at most).
Document, document, document!
You shouldn't allow users access to your source code for this. You should document your API thoroughly regarding details which methods the user can use, what sort of data it expects to receive, and what sort of data you will get back from it (including all errors, possible problems with the users request, and how to fix their requests). Make sure you heavily test these too, and make sure that you can't perform any sort of malicious actions with your API. It's also a good idea to give your documentation to another person and ask them to read it. If you've missed something important, you will know afterwards because there will be a clear gap in their knowledge of the API.
What, not how
Users should know what a function should do, but not how it does it. For example, I could use /api/GetUserById. I should know that I can get a user - I shouldn't know how it gets the user. The only thing I need to know is that I perform this call and I get back a json object with details about the user. That is it.
As with any of my posts, if there's something I've missed or something you need further clarification on, please let me know in the comments and I'd be happy to explain further. I hope this helps
I have a little question because I am trying to understand the notion of authentication server. I saw lot of diagram explaining for example oauth. But there is something I do not understand.
It is the validation of the token to let access to the resource server.
I made a little diagram to explain where is my question.
Thanks a lot for your answer :)
Have a nice day
There are basically two options:
Check the authorization server to see if the token is valid.
Issue self-validating tokens (using cryptographic techniques) such that the resource server can quickly determine the validity of the token.
I believe that number 2 is far more common, because it's capable of much better performance.
Here is a good article laying out the pros and cons of the two approaches. Their performance summary:
The self-contained + RSA signed access tokens emerge as the clear winner from this benchmark, by a factor of at least ten.
No, Resource Server should be able to accept (decrypt and validate expiration, roles, ...) the access tokens issued by the Authorization Server and respond with the protected resource if the the access token is valid.
Check this link.
I'm building a single-page web application, fully based on RESTful API. I've seen several topics in that matter, but some things remain unclear for me.
I will need users to log in. Here are some of my ideas:
I can send e-mail and password to API and use basic auth. I'm not sure where should I keep password, should it be encrypted and if so: how?
Can I use built-in session system instead? Is it wrong to use cookies directly in the RESTful API? Why is it so popular to send credentials/keys to API itself instead of using cookies?
I thought about having one API key per user, return it in login action and keep it in localStorage. I guess it's not the greatest idea to have just one key per user?
Then, I came up with idea to have separate keys table and add random keys each time somebody logs in. On logout, the key would go away and no longer be valid. This is more secure than previous idea.
How is it solved in simple projects? I'd like to make it simple but not ridiculously inserure.
Please help.
The commonly approach is to use the header Authorization in REST. The state of the application must be on the client side with REST and shouldn'a be tied to a particularly client kind (browser with cookies)
I think that this link could be helpful:
Implementing authentication with tokens for RESTful applications : https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
There is also à great question to à similar question here : https://softwareengineering.stackexchange.com/questions/141019/should-cookies-be-used-in-a-restful-api
Hope it helps,
Thierry
I'm struggling with an issue here. I've searched repeatedly for answers, but have been unable to find the exact answer I'm looking for. I'm attempting to build a secure authentication method for a REST api. My question is, how do we handle a login for a REST api?
Since a REST api is meant to be stateless every time, does that mean we need to store the client's username/password on the client's end (perhaps hashed), and send it in with every request? I'd be much more comfortable using a system like authentication tokens that are created upon logging in the first time, but does that go against the basic rules of REST, since this technically creates a "state" on the server?
What is the best and most practical method to handle this? As I wrote earlier, I'm struggling to come up with an answer to this; maybe that is due to this problem not having a clear answer, but I honestly don't know.
Thanks in advance.
That's also my understanding of REST: clients send login/password to the server along with every request. The server has to authenticate the client based on this information only. With regard to the Hypermedia principle of REST, having a user logged in is not an application state, in my understanding.
I'm writing an API where partners will ingest my content. There is no user data to speak of, and it's all-or-nothing access. I'd eventually like to be able to restrict some partners to certain elements of the site, but that's down the road.
Does a two-legged oAuth fit my needs well, or should I just provide an API key and a secret key to use in signing the requests? I feel like oAuth might be overkill.
Thanks!
This blog post is a little old, but has some good info.
http://blog.apigee.com/detail/do_you_need_api_keys_api_identity_vs._authorization/
It sounds like an API key would be your best bet for now...who knows, you may never need oAuth, but you could always migrate to it in the future.