The REST API for Mongolab is cool. I can use that for analytics in my website directly using the following javascript, provided on Mongolab's support page. Only if I can understand how the authentication actually works. The API key mentioned in the URL could be easily copied by anyone who'd view the html source. The Mongolab control panel does not offer any registration for my website that'd assure me that the api key will be validated only if coming from my domain.
How does this authentication work?
$.ajax( { url: "https://api.mongolab.com/api/1/databases/my-db/collections/my-coll?apiKey=myAPIKey",
data: JSON.stringify( { "x" : 1 } ),
type: "POST",
contentType: "application/json" } );
Excellent observation, and great question.
Currently, all API keys have read and write access to the databases associated with the user's account, and any agent possessing an API key can successfully issue any such request.
As you observe, this very basic pass key is not designed with any kind of fine-grained security in mind.
However, we're working on a batch of new REST API security features aimed at precisely that.
Contact us at support#mongolab.com if you'd be interested in discussing the details.
I'd like to use MongoLab service for my first AngularJs app with MongoDB, but MongoLab is not ready for production with a web app that wants access from the front end to the MongoDB.
It's very easy to get the API key in the browsers network traffic (see screenshot below, the apiKey is in plain text there) and then any one can have full access to the DB. So messing around with the MongoDB would be no problem.
I haven't found a workaround for MongoLab yet. At the moment, I think I will use another service like https://www.dreamfactory.com/
I haven't tried it in detail yet but it looks great for an AngularApp with MongoDB and I need to check how they implemented the security of the api. On the first look, it looks like it is working with session tokens to secure the requests to the database.
You have an API key for doing http request to your DB using their REST API. For example, if a user wants to log in I make a request with a GET method like this:
https://api.mongolab.com/api/1/databases/name_db/collections/users/put_your_params_like_username_and_pw?apiKey=xxxxxxxxx
And then you analyze the response to that request. It is not the most secure DB in the world but it is getting better.
If you want more info I talk about that in my blog: http://lolapriego.com/blog/?p=16
Related
I want to create a custom API that behind the scenes, call number of other APIs which use OAuth 2.0 for authentication. I want to manage this internally so that my custom endpoint somewhat abstract this.
Or to begin with I want to do what app like buffer (https://buffer.com) do - where you connect to different social services and than post your status.
How can I achieve this in .NetCore ?? I don't want to login with these (a lot of samples are catering this scenario), user login is different than this. I just want to establish these connections (like API Connections if you look at Azure API Management) and then perform some operations against those endpoints.
I hope i convey my point. please let me know if this isn't clear.
Thanks
Sanjay
OAuth2 systems are all based on the same workflow.
here's an authorization url, you pass some ids in an authorization header, if everything is correct you get a token, you then use the token to do whatever you are allowed to do. What changes are the credentials you use for authentication and the urls you hit for the various parts of this workflow.
You could write your own OAuth2 library which deals with all this, that's pretty much what I did and simply changed the details for every specific system I had to interact with.
This being said you can always use one of the existing implementations to connect to the various systems you care about, they all have an API you could use, all you have to do is make sure you follow the OAuth2 flow correctly.
I'm implementing the Socrata API to be able to parse publicly-available data from the City of Chicago open data set. I am really just concerned about the data itself, so I did not initially think that I would need to implement OAuth2 through an app exposed via ngrok to be able to GET the data.
My initial attempt was to take the GET requests mentioned in their documentation and try to get responses through Postman.
Here's an example of such an attempt:
I also added my Socrata App Token as a param in the querystring, but the same message was shown.
So I tell myself, ok, maybe they deprecated GET requests without making the client go through OAuth2. If they didn't deprecate these GET requests, I would prefer not to have to deal with OAuth2, but I began implementing the authentication process and everything went successfully until I got to the following instructions found here:
I have every single value that needs to be included in that POST request except for 'authorization_type'. Where does this come from? I tried leaving 'authorization_type' in as a string, but received a response similar to the 'Invalid username or password' message in the top image in this question.
Are you only accessing public datasets from Chicago's data portal? From your screenshot it looks like you're trying to access the Building Permits dataset, which is public.
Authentication is only required for modifying datasets or accessing private data, so chances are very good you don't even need to authenticate. Just include an application token with your request for throttling purposes.
Glad to help you figure out your OAuth workflow, but it sounds like it might be unnecessary.
I want to integrate the foursquare API in my website but I'm not that familiar with API security so I want to make sure I'm doing it right.
I want to search for venues in an area like the documentation states:
https://api.foursquare.com/v2/venues/search
?client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
&v=20130815
&ll=40.7,-74
&query=sushi
Using javascript however, I don't feel comfortable that the client secret is exposed in my code like this, because if someone looks at my source they have the client_id and client_secret which makes it possible to authenticate themselves with my code:
https://developer.foursquare.com/overview/auth
Isn't that the same as, "hey look at my source code, my username = "someusername" and my password is "somepassword"?
Shouldn't the "client_secret" remain secret like it says? Or am I looking at it the wrong way?
I think the issue is that you're trying to access the Foursquare API using Javascript, which is executed on the client side, so yes, anybody using your website can, with a little bit of investigation, see the secret key that you're using, which is something that you definitely don't want to do.
The way to get around that is not to access the API using code that is executed on the client side. Whatever language you have building the website on the server side should be the code that accesses the API (using the auth credentials that you have set up) and then returns the results of the API call to the rest of the code.
Alternately, you can get users to authenticate with Foursquare and get an access token, which you can then use in user-specific API calls, and it won't matter if those are executed on the client side. I think this is the relevant page in the documentation for using that method: https://developer.foursquare.com/overview/auth#access
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
We have a large high traffic site with a lot of data on it (similar to Kickstarter), and we want to provide to our content/project creators a means of pulling their data from our site via an API.
Someone suggested I use OAuth, however my experience with OAuth is limited to setting up a twitter datasource.
What I want to do
Provide a user an Application ID and a 'secret'
Allow this user to connect to our application via an api endpoint, authorizing themselves using the api ID and secret
Once verified, allow this user to pull only their data from the application
The data that a user can pull: votes they have cast, pledges they have made, purchases they have made, projects/ideas they have launched, data about those projects/ideas (votes/purchases/orders/cancellations etc)
My question is:
Is OAuth overkill?
Is there a better way to handle a user/users website to connect to our API and pull/verify certain data by using the API we make available, while requiring each incoming request to be authorized for the user/site initiating that request.
Ideally, we will have an endpoint that is accessed as:
https://api.oursite.com/request/params
We want this to be as simple as possible for our users that wish to implement this interface. Thanks for your help!
Generally it's OAuth, in combination with SSL. That's the standard and is likely to stay. Before we saw also logins: username + password to access an API but that's becoming less and less.
So the suggested way is OAuth. There are no serious other solutions yet. To make it easier to adopt your API you could release some classes in some development languages so developers can have a quick start. You could start releasing those classes at for example GitHub to raise adoption of your API and get a quick access to developers. They might, if you do well, even start improving it.