So I'm wondering how I can only make sure that CRUD operations to my restful api is only accepted by my own application and not by outsiders? My application consists of Node js as backend who makes the restful api and android as front-end who communicates with the RESTful api. I've seen JWT tokens but it only works with login system but I have an application without login system.
The reason why is that I don't want to let outsiders read or even write data on my api from for example POSTMAN. How to make sure that people who muse my app can perform CRUD operations to my API?
The Difference Between WHO and WHAT is Accessing the API Server
Before we can understand the options to address your concern I would like to clarify a common misconception among developers regarding the WHO vs the WHAT is accessing an API server.
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
The Intended Communication Channel represents the mobile app being used as you expected, by a legit user without any malicious intentions, using an untampered version of the mobile app, and communicating directly with the API server without being man in the middle attacked.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of the mobile app, a hacker using the genuine version of the mobile app, while man in the middle attacking it, to understand how the communication between the mobile app and the API server is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate each one here.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
The WHO is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
OAUTH
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the original version of the mobile app.
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the mobile app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise you may end up discovering that It can be one of the legit users using a repackaged version of the mobile app or an automated script that is trying to gamify and take advantage of the service provided by the application.
Well, to identify the WHAT, developers tend to resort to an API key that usually they hard-code in the code of their mobile app. Some developers go the extra mile and compute the key at run-time in the mobile app, thus it becomes a runtime secret as opposed to the former approach when a static secret is embedded in the code.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?, and that you can read in full here, that is the first article in a series of articles about API keys.
Your Question
So I'm wondering how I can only make sure that CRUD operations to my restful api is only accepted by my own application and not by outsiders?
Defending and locking an API server to your own app is not an easy task, because any secrets used to identify the WHO or the WHAT are relatively easy for an attacker to grab. You can read the article How to Extract an API Key from a Mobile App by Static binary analysis where I demonstrate how they can be extracted with the help of several open source tools, like by using the Mobile Security Framework, or you can read this other article Steal that API Key with a Man in the Middle Attack, that uses the open source tool MiTM Proxy to launch a man in the middle attack to extract the API key.
By now you may have already realized that is very hard to defend an API server from being abused by attackers, because after they have extracted the secrets to identify the WHO and the WHAT is making the request, they can use the tool you are concerned about, Postman, or any other one to attack your API server, and pretend to be the legits WHO and WHAT.
You may be asking now... How can I defend my API server?
Defending an API Server
As a best practice a mobile app or a web app should only communicate with an API server that is under your control and any access to third party APIs services must be done by this same API server you control. This way you limit the attack surface to only one place, where you will employ as many layers of defense as what you are protecting is worth.
You can start with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the unauthorized ones.
Regarding APIs serving mobile apps a positive identification model can be used by using a Mobile App Attestation solution that guarantees to the API server that the requests can be trusted without the possibility of false positives.
Mobile App Attestation
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered or is not running in a rooted device by running a SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device is running on.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
In Conclusion
The reason why is that I don't want to let outsiders read or even write data on my api from for example POSTMAN.
Well Postman uses a custom http header by default, thus is easy to block requests from it, but this will only works if the user doesn't disable this feature of Postamn, and attackers always disable them, therefore this measure will not be very effective, and once Postman is not the only tool out there, you need to be more sophisticated in your defenses than this.
How to make sure that people who muse my app can perform CRUD operations to my API?
I think you want to mean that only people using your app can perform the CRUD operations.
In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
So my recommendation is that you implement a Mobile App Attestation solution, because its a positive model that can address your concerns.
I am developing an application that extracts Swagger specifications of other applications and extrapolates an UI for them, with all the needed functionalities to interact with the API.
Now I am facing a problem when trying to implement the OAuth2 authentication. With OAuth2 you always need a registered cientId to get the access token. The problem is that the swagger specification doesn't require providing a clientId in the OAuth2 security definitions.
This means that the clientId should be registered for my own application in any OAuth2 server that the users want to access, and get the data for my application, and not for my user's applications. Of course this is not the way my application should work, as it's supposed to maintain the user's application identity.
My questions are:
Should the clientId be added to the OAuth2 definition?
Is it possible to implement what I need without having to register my app for all the OAuth2 servers that my users want to access?
Maybe I am missing something, any help would be much appreciated!
Thank you
I don't think ClientID would be part of the definition--it's typically part of the credentials that are provided to a specific implementation for connecting to a service. So each integration would be a different "client" and therefore a different ClientID
The API is a backend to a Web app and mobile app. I don't need user authentication. I simply need a way to secure access to this API.
I just need to ensure only web app and mobile app can talk to this backend and no one else.
If you are indeed using Google Cloud Endpoints, what you want is easy to do.
You need to log into the developer console and go under API Manager -> Credentials. There you can generate access keys for each of your clients. Then you add those tokens to your endpoints using the provided annotations. You cloud endpoints will only serve requests that come from one of the clients you have specified.
I am developing an HTML5 mobile application which I am planning to port to Android also using Phonegap. I want to use AWS DynamoDB for storing my users data. I know that amazon has a http api but it is too complicated. Some of my queries are
If I use the HTTP api, wouldn't it expose my credentials? (Same qquery for dynode)
What are the alternatives? I have a EC2 instance so hosting a server is not a problem.
I would appreciate your suggestions on this.
If you connect directly from your phone application, to dynamodb, you will risk exposing your credentials.
The general way to handle this is to have a json REST api through which the phone application can authenticate and make requests to the datastore. Your application would communicate with this api.
In this case, each user would likely have its own authentication to your server application.
tech stack
Ruby on Rails
RESTful JSON API
Backbone + Handlebar templates + Underscore + JQuery
OAuth2
I am working on a webapp where I would like all the communication between the browser and controller via JSON RESTful API. I would also like to use the same API for different client apps like mobile and desktop apps.
I am considering the OAuth authentication mechanism for API. This fits in perfectly with Desktop and Mobile app. However if I would use the OAuth for front end too; then that basically means that an end user would be issued an access_token and that would be used to make subsequent requests.
Is there a clean way to handle session timeouts ONLY in webapp while using the same oauth token strategy for Authentication without having to wrap it with a separate persistent session?
Are there any good practices or frameworks that allows us to expose API for client as well as webapp consumption while catering to the specific nuances of each?
I know Foursquare currently uses the OAuth API for both clients and web; but curious as to how they handle authentication with that?
Any help with ideas and implementation would be much appreciated.