Can API gateway access to database directly?
We have a client we need to integrated our product using REST API. We already provide some kind of REST API, but it is not suitable for their usage, thus they asked us to provide specific REST API for their usage.
So, we decided to implement API Gateway pattern to call our API and perform some response transformation. And here is the issue. Our API does not provide all the data needed by this customer in responses, but the data are stored in database. And I am wondering if it is OK to talk to database directly from API Gateway or we should create a specific REST API and call that instead.
If you have a kind of database handler that handles access and visibilty concerns it should be okay, but for further purposes you should think about providing database access via REST too, with a user authentication
There is no direct connection between API gateway and database instead you can connect your DB with lambda and use lambda as an integrator
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 have a database with all my employee's information. Should I build an API or should I give direct access to the database?
The API could be built with Node.js and be a REST API. The database access could be given with different database users / different permission sets.
I'm confused because when I query an API, I usually get JSON data back which is awesome. So I wonder if only I can build an API that contains all the data I want and when I query it, I can have my employee's info back in JSON format.
There are reasons to use a REST API. For example you'll have a app, that will be available to the public, you might don't want to write your SQL queries directly in your code, as well as the credentials to connect to your server. Anyone with the knowledge could decompile your app and see your code and have access to the credentials to you database server. The good approach here is to write an REST API to handle the flow of data between your app and database, since REST API should be designed to be accessed publicly, you'll only have to pass in the data, or just call the api you need, you don't need the servers credentials to connect. If you are going local, then you could use the database approach of yours. Since your app will be used only by your clients.
I have developed a REST/JSON API. The API exposes a lot of features. The API will be consumed by applications we design internally (mobile apps and web apps), by applications designed by our resellers and by applications designed by businesses. I am looking at securing the application by implementing authentication and authorization. I have 'googled' a lot but my research has left me with more questions than answers.
Our internal application will be used by end users registered on the application. In essence, our application is just a client taking request from the end user, taking it to the REST API and retrieving the data for the end user. Our internal application should be able to perform all the operations exposed by the REST API. What is the best way to handle user login on our internal application? HTTP Basic over SSL or OAuth?
Our reseller applications can create users like they own the users but ultimately the user details get stored in our database. The reseller application will just act as a client taking request from the user and fetching user data. Our resellers applications should only be restricted to some operations of the REST API. What security mechanism will I use to implement this kind of authorization and user login?
I hope my question is clear. Thanks for the help.
From what I understood in reading this there are two parts to your question:
What is the best authentication method for my API?
I recently developed an authentication system for an API that was modelled on OAuth but didn't have every single one of their specifications. The system was basically the same as what Amazon use for their API. [This article]1 is very helpful if you want a secure API authentication model without having to use OAuth.
The model uses these principles:
Authentication data will be passed with every request to the API server
Requests will include a Unix timestamp from when it was generated
The entire request (including the timestamp) will have an HMAC hash generated and sent alongside the rest of the data. The hash is generated using a private key that only the API server and the API client know.
The API takes the data (including the timestamp), generates an HMAC hash using the private key for that user (identified by a user ID, user name, public API key, whatever) and compares it to the hash sent with the request. If this was successful, regular authentication proceeds and the request is processed. Note: the API will check the timestamp and compare it to its own to make sure the request has occured within a valid timeframe of, for example, 30 seconds, 5 minutes, 10 minutes, etc.
Of course, you can use regular HTTP authentication over SSL/HTTPS also, but I find this way to be very good because you achieve a high level of security without needing to implement every aspect of the OAuth protocol.
How you authenticate is up to you essentially. I prefer to go with methods employed by large, trustworthy organisations (such as Amazon). I personally didn't want to go the whole hog with OAuth like Twitter, Facebook etc.
How should I allow different users to access different endpoints in my API?
You should have an internal map in your API server which contains records allowing or denying specific API accounts from accessing certain endpoints. In my API server I decided that all endpoints would be "allow" by default, and I would specify which accounts would not be able to access certain endpoints.
You could also set up different groups or types of API access accounts which could have group permissions like this.
My suggestion would be to [read this article]2 twice, or three times, then read it again. Then, implement the methods suggested within.
Personally, I think the best method for ensuring as much security as possible is to restrict absolutely everything in regards to the request to be within a set of boundaries that you define, e.g. I want this endpoint to only be accessible by GET HTTP requests (all other HTTP methods will throw an error), up to 3 times daily per account, within a 30 second timeframe of request to server, only allow a narrow range of data to be returned, etc.
Limiting the HTTP method is very important to reduce the risk of your API doing things it shouldn't, especially with a RESTful API as endpoints can be used to do multiple things depending on the request method. You can even set your permissions for each API account to restrict certain methods on each endpoint, e.g. API user xxx can GET information from an endpoint but cannot POST, PUT, PATCH etc, or API user xxx2 can POST data but cannot GET any, etc.
[EDIT] 1 and 2: www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ (not completely removing the link but keeping the url unlinked as it no longer works/redirects to random sites)
I have created an app and some REST API on Google Appengine and deployed it to
www.my-appspot-id.appspot.com
I'm using Google Datastore to store my data and have created API's to access that data.
However, i can access my API directly also using
www.my-appspot-id.appspot.com/_ah/api/explorer
which means anyone can access them and can manipulate the data which i don't want.
How to restrict access so that nobody but some particular registered set of users can only use it?
I stumbled upon this tutorial recently, might be of some help.
I think you need to authenticate your endpoints and authorize only some client id.
OAuth 2 authentication : https://developers.google.com/appengine/docs/python/endpoints/getstarted/backend/auth
Allowed client ids and audience : https://developers.google.com/appengine/docs/python/endpoints/create_api#allowed_client_ids_and_audiences
To answer your question : you can't.
Google Cloud Endpoints is based on the explorer api: everybody will be able to navigate into your API, and see the differents methods available.
BUT if you add an authentication to your methods, the visitor will not be able to execute them.
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.