Related
We want to write an react native app that:
-gets data over bluetooth from devices
-the app should send the data to our api
-it's important that the data is not tempered with or changed in any way
-the app is the only one that can send data to our api
I already read a lot about:
iOS - Keychain Services and
Android - Keystore
on the React Native docs: https://reactnative.dev/docs/security
And SafeNet(Android) or DevieCheck(IOS) (never mentioned on react native docs or articles I read)
What security layers should we use for our use case to make the api most secure and how can I implement them in react native?
We want to use the data from the api to verify the correctness of the same data passed to a smart contract that compares and evaluates them.
YOUR PROBLEM
We want to use the data from the api to verify the correctness of the same data passed to a smart contract that compares and evaluates them.
I congratulate you by having taken the time to understand that the API sitting in front of a blockchain needs to be protected against abuse in order to prevent the blockchain from ingesting unwanted data.
Defending an API it's not an easy task, but if you read carefully all I am about to say I hope that by the end you will have a new perspective on API and Mobile security, that will allow you to devise and architect a robust and secure solution.
WHO IS IN THE REQUEST VERSUS WHAT IS MAKING THE REQUEST
-the app is the only one that can send data to our api
This is a very hard problem to solve, but not an impossible one. To understand why you need to first know the difference between who is in the request and what is making it, otherwise any security you add may not be protecting your API as expected.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
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.
So, think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
DATA INTEGRITY
-gets data over bluetooth from devices
-the app should send the data to our api
-it's important that the data is not tempered with or changed in any way
This is also very hard to solve. During the process of collecting the data and sending it to the API the data can be tampered with in several ways.
Manipulate Data with an Instrumentation Framework
-gets data over bluetooth from devices
While the data is being collected form the devices an instrumentation framework can be used to manipulate the data before sending it to the API. A popular instrumentation framework is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
So, the attacker would inject a script to listen at runtime to the method that collects the data or to the one that sends the data to the API and then tamper with the data its being sent.
the app should send the data to our api
Manipulating Data with a MitM Attack
Another alternative is for the attacker to also use Frida to perform a MitM attack to allow a tool like mitmproxy to intercept and modify the request. You can learn how to perform a MitM attack with Frida by reading my article How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
The injection of Frida scripts at runtime allows for almost unlimited possibilities in how to tamper with your data integrity or whatever the mobile app is doing at runtime.
POSSIBLE SOLUTIONS
Secure Storage
I already read a lot about:
iOS - Keychain Services and
Android - Keystore
on the React Native docs: https://reactnative.dev/docs/security
Using this mechanism is recommended, but you need to be aware that anything that is stored in secure storage will need to be accessed and used by the mobile app at some point, and this is when the attacker can use an instrumentation framework to hook at runtime into the mobile app code. For example, when retrieving a securely stored secret the attacker can extract it to use outside of the mobile app to automate API requests as if they were from the mobile app.
So, use it to make it harder for less skilled attackers to tamper with your mobile app, but always remember that more skilled attackers may find their way around it.
Protecting Data Integrity in the Mobile App
-it's important that the data is not tempered with or changed in any way
To protecting data from being tampered with before it arrives to the API server it's necessary that you employ some solutions, like RASP:
Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.
The issue of using only RASP is that the API server doesn't have visibility for the ongoing attacks on the mobile app, therefore not able to refuse requests from a mobile app under attack. Also, RASP can be bypassed by skilled attackers with the use of instrumentations frameworks, and the API server will not be aware of this happening, therefore will continue to serve requests, because it doesn't have a mechanism to know that what is making the request is indeed a genuine and un-tampered version of your mobile app.
Defending the API Server
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
One of the solutions proposed is to use a Mobile App Attestation solution that runs outside the mobile device, for example on the cloud, therefore doesn't make client side decisions about the state of the mobile app and device is running on, instead they are done in the cloud service and transmitted to the API server as signed JWT token, that the API server can then used to verify that what is making the request is indeed the genuine and un-tampered version of the official mobile app.
Android Safetynet and iOS Devicecheck
And SafeNet(Android) or DevieCheck(IOS) (never mentioned on react native docs or articles I read)
Using the Android SafetyNet and iOS DeviceCheck runtime protections is for sure a good starting point, but you need to be aware of their scope, limitations and complexity. They can be complemented with a robust Mobile App Attestation solution to give you an higher level of security and confidence that your API server will be able to know when the request is not from what it expects, a genuine and un-tampered version of your mobile app.
Security Layers
What security layers should we use for our use case to make the api most secure and how can I implement them in react native?
I would not be approaching here how to implement it in React, because that is a huge topic and the exact code will depend on your current implementation, but I will summarize here the key points.
Security is always about adding as many layers as you can afford and are required by law, standards and business requirements. To summarize you should consider the following topics:
Don't hardcode secrets in your mobile app code, but if you really want to do it, at least use Native C code.
Obfuscate your mobile app code, because this will make it harder to reverse engineer the mobile app code in order to use instrumentations frameworks.
Use runtime protections in your mobile app code and give preference to the ones that don't make decisions on the client side and allow for the API server to verify that the request is indeed from what it expects, a genuine and un-tampered version of your mobile app, like describe in the Mobile App Attestation I mentioned previously.
Use certificate pinning to the public key to prevent MitM attacks, but wit h the awareness that it can be bypassed. I recommend you to read the section Preventing MitM Attacks in this answer I gave to another question where you will learn how to implement static certificate pinning. If you can, try to use instead dynamic certificate pinning to allow to remotely update the pins used by your mobile app.
In your API server you can use rate limiting but do not give back in the headers the info about the rate limit available, because that is like putting the key to your front door under the mat.
You can use Artificial Intelligence solutions, but be aware that they work in a negative identification model and are prone to false negatives and positives. If using a mobile app runtime protection that lets the API server know when is under attack then the use of AI solutions can be postponed until the API server needs to use other type of clients, like web apps.
This is not an exclusive list of topics you can consider to use in order to secure your mobile app and API server, but are the ones I think that more important for you to focus on.
DO YOU WANT TO GO THE EXTRA MILE?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
So I grant access of my resource to application A, and that application gets that access token. It is just a string. Sometimes the application will pass that access token to its backend server, and then use it to retrieve my resource. Usually the access token is valid for say one month.
Now my question is, what if application A leaks my access token, so any application B can use that access token to get my resource, which is not what I want. I only want application A can access my resource, not application B.
How do we trust application and give it my access token?
YOUR PROBLEM
Usually the access token is valid for say one month.
Using 1 month to the access token expiration time is way to long, not matter if is for admin or normal users.
Depending on your use case I recommend you to use the access tokens with an expiration time in the range of minute, lesser time you can have better will be for security.
So I would recommend you to switch to use refresh tokens, that will keep the access tokens short lived while refresh tokens can be long lived, but in the hours range, not days, weeks or years.
Refresh Token flow example:
Sourced from: Mobile API Security Techniques - part 2
NOTE: While the above graphic belongs to a series of articles written in the context of mobile APIs, they have a lot of information that is also valid for APIs serving web apps and third party clients.
By using the refresh tokens approach, when a client request fails to validate the short lived access token will mean that the client needs to request a new one by sending a refresh token in order to get a new short lived access token.
The important bit here is that the refresh token should not be sent to the browser, only the access token can be sent, therefore your third party clients must kept refresh tokens private, aka in their backends, therefore they MUST NOT send refresh tokens from javascript, instead any renewal of the short lived acess tokens MUST BE delegated to their backends.
Now my question is, what if application A leaks my access token, so any application B can use that access token to get my resource, which is not what I want.
That's why you should use the Refresh Tokens approach I mentioned earlier, because you limit their access to the amount of time remaining in the access token, and this is why I said that the short lived access tokens should be in the range of minutes.
I only want application A can access my resource, not application B.
I am gonna tell you a cruel truth... this is not doable at 100%, specially for web apps, where you can just hit F12 to access the developer tools console and search for the access token, or if you prefer to right click on the page and select view source.
Mobile apps seem to be more secure at a first glance, because they are shipped as a binary, thus you would expect to be hard to reverse engineer it? Wrong, it's indeed easy with the plethora of open source tools that we can use to reverse engineer them, and my preference goes to the MobSF:
Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.
So if you cannot find the access tokens via static analysis, then you can resort to dynamic analysis with open source tools to, like Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
And if that's is not enough you also perform a Man in the Middle(MitM) Attack wit another open source tools, like mitmproxy:
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
So, stealing your access token for a mobile app is not as easy as in the Web App, but it's not that hard to.
POSSIBLE SOLUTIONS
How do we trust application and give it my access token?
I don't know if your application is a web or mobile app, therefore I will show you possible solutions for both.
Before I mention the possible solutions, I need to first clear out a usual misconception among developers, regarding who vs what is accessing the backend. This is discussed in detail in this article, where we can read:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
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.
If you still have doubts please go and read the section of the linked article, that also includes a graphic to help with understanding this. The article is in the context of a mobile app, but for understanding the difference between what and who is accessing the backend, the references to mobile app can be replaced with web app.
For Web Apps
If your use case is a web app the most affordable solution to try to mitigate the who vs what is accessing your backend it's by using:
Google Recaptcha V3:
reCAPTCHA is a free service that protects your site from spam and abuse. It uses advanced risk analysis techniques to tell humans and bots apart.
This is uses User Behaviour Analytics(UBA) in a best effort basis to tell appart who and what is accessing your backend.
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.[1] Instead of tracking devices or security events, UBA tracks a system's users.
This is prone to false positives, therefore you need to be careful when deciding to accept or not the request based on the score returned by reCPATCHA V3 for each request:
reCAPTCHA v3 returns a score for each request without user friction. The score is based on interactions with your site and enables you to take an appropriate action for your site.
For Mobile Apps
As you saw by the plethora of tools available to reverse engineer the mobile apps, statically or dynamically, the access token to identify your user is not that safe, plus this only identifies the who in the request, not what is doing it.
The solution that can let your backend to be sure that the request is indeed from the same exact mobile app that was uploaded to the Google Play or Apple store is a Mobile App Attestation solution, that is a concept that introduces a new way of dealing with security for your mobile app and backend in an unified manner.
The usual approaches focus to much on the mobile app side, but in first place the data you want to protect is in your backend server, and it's here that you want to have a way to know that what is making the request is really the thinh you expect to be, your genuine mobile app.
The Mobile App Attestation concept is described in this section of another article I wrote, from where I will quote the following text:
The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.
In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework (Frida, xPosed, Cydia, etc.) and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.
On a 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 know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.
The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.
So this approach will let your backend server to trust with a very high degree of confidence that the request is coming indeed from the same exact mobile app you uploaded to the Google Play and Apple store, provided the JWT token has a valid signature and expire time, and discard all other requests as untrustworthy ones.
GOING THE EXTRA MILE
To finish my answer I cannot resist to recommend you the excellent work of the OWASP foundation, because off their excellent work and for me no security solution for web and mobile is complete without going through their guides:
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
The Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
I am using the Goodreads api to get book data for my react native app. I have to use a key for using the api. Is it OK for me to store the api key on the app itself or should I put the key on a server that redirects all the data to the app?
Is it OK for me to store the api key on the app itself
No, because as I demonstrate in the article How to Extract an API Key from a Mobile App by Static binary analysis it can be extracted with the help of several open source tools, like by using the Mobile Security Framework, but you can also grab the API key with a MitM attack, as I show in the article Steal that API Key with a Man in the Middle Attack, that uses the open source tool MiTM Proxy.
If you leave a third party API key in the mobile app, then they are up for grabs from attackers, and when they start using it without your knowledge your bill in the third party provider may go through the roof before you acknowledge that something is wrong, and on that time the only solution is to revoke the API key, thus shutting down the use of the mobile app, and if you make a new release of your mobile app with a new API key it will be just a matter of hours until the attacker come back and steal the API key again.
or should I put the key on a server that redirects all the data to the app?
Yes, and this is a good approach, because now you have only one place to store and protect all third part API keys. This have the benefit to let you control and throttle the use of them as you see fit.
With this solution you still need an API key in your mobile app to allow access to your API server, but while you continue vulnerable for attackers to steal it, you are now in direct control of throttling the access to your API server and if you identify in each access the WHO and the WHAT is accessing the API server, then you have a more fine grade control, but attacker will continue to be able to slip between all our defenses, because is very hard to know WHAT is accessing the API server.
You may be thinking by now... do you mind to explain the WHO vs the WHAT?
The Difference Between WHO and WHAT is Accessing the 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 problem is not solved yet
Now that you know the difference between WHO and WHAT is accessing your API server you must have realized that your API server is still vulnerable to be abused by attackers.
You can resort now to employ several layers of defense, starting 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
Use a Mobile App Attestation solution to enable the API server to know is receiving only requests from a genuine mobile app.
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.
Summary
Anything that runs on the client side and needs some secret to access an API can be abused in different ways and you must delegate the access to all third part APIs to a backend under your control, so that you reduce the attack surface, and at the same time protect their secrets from public pry eyes.
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.
For react native use react-native-config library. While using this library you can secure your api keys as well as you can save more secret keys which use in the native code. Like we can save onesignal, codepush etc keys.
https://github.com/luggit/react-native-config
Store them in a .env file like this API_KEY=yourKey.
Install npm package react-native-dotenv.
Then import to to files as needed with react-native-dotenv package;
import { API_KEY } from 'react-native-dotenv'
The .env file should never be committed to Github.
I have a mobile application which relies on a Windows Azure App Services Back-end. I want to tie down some security vulnerabilities. For example, someone can currently access all my records, modify or delete them. Not Ideal...
I only want users to be able to access their own records (data privacy) and I want to ensure that only my application can POST data to the server, i.e. an unofficial potentially corrupted app shouldn't be able to POST data and corrupt my database. Maybe some sort of TLS etc. approach might do this? This restriction (if possible) would likely allow me to implement the access-to-own-records-only logic in the mobile app rather than backend?
How could I ensure only legitimate versions of my app can interact with my back-end?
Azure Mobile Apps (an SDK on top of a standard Node/Express or ASP.NET app that can be deployed to Azure App Service) provides a mechanism that your web or mobile app can access records in a SQL database. The users ID is stored alongside the record on a POST and the users ID is also used as part of the query when returning records.
See https://shellmonger.com/30-days-of-azure-mobile-apps-the-table-of-contents/ - particularly Day 6 (for Node/Express) and 18 (for ASP.NET)
As to your last question - how to ensure only legit versions of the app can interact with your backend - you can't. Trivially, you might think to use a shared secret that needs to be passed IN ADDITION TO other authentication requirements. However, this does not stop someone sniffing the wire and using the same shared secret. There is virtually no way that you can stop a determined player from accessing your backend without using an approved app.
Is it possible to identify (authenticate) a mobile application HTTP request ?
for example a request from a web server can by identified by the domain or IP, assuming I know from where it should come from I can accept the request or deny if it came from an unexpected origin.
doe's mobile application has some sort of unique id (that cannot be mimicked)?
If you need to make secure HTTP calls (webservice API) from a mobile app (a native compiled app), you can try the following approach:
Edit: This approach assumes that you can't rely on the user operating the app for authentication purposes (because then you could simply ask the user to type in a secure password in the app).
Assuming you are implementing the app, save some sort of secret API key in the code.
When the app makes an API call via HTTP, it will always be done using HTTPS (so everything is encrypted).
The app will send the secret API key as a URL parameter.
The server will authenticate by checking if the secret key is correct.
Sniffing the app traffic will not reveal the secret key (because of the HTTPS).
You are mostly vulnerable to someone reverse-engineering your app to discover the secret key inside. This can be made tough by using various obfuscation and anti-debugging techniques, but cannot be made truly impossible. As long as you're using a compiled language (like Objective-C, not JS for a web-app) this will already be tough without any special games. If you avoid placing your API key string as-is and compute it using some short code in the app, you've made it about 1000 times tougher to discover.
Without knowing more about your specific problem, it's hard to suggest alternate approaches. Please give more details if you are looking for something different.
There are two methods used in practice. HTTP basic authentication (not much secure for mobile apps) and OAuth2 (secured compared to HTTP basic authentication).
HTTP Basic Authentication: The process is simple for both technical writers of API services, and also developers using them:
A developer is given an API key (typically an ID and Secret). This API key usually looks something like this: 3bb743bbd45d4eb8ae31e16b9f83c9ba:ffb7d6369eb84580ad2e52ca3fc06c9d.
He is responsible for storing API key in a secure place on their server, so that no one can access it. He makes API requests to the API service by feeding the API key in the HTTP Authorization header along with the word 'Basic' (which is used by the API server to properly decode the authorization credentials). The key is also Base64 encoded.
For example key could be: 3bb743bbd45d4eb8ae31e16b9f83c9ba:ffb7d6369eb84580ad2e52ca3fc06c9d
encoded in base64: M2JiNzQzYmJkNDVkNGViOGFlMzFlMTZiOWY4M2M5YmE6ZmZiN2Q2MzY5ZWI4NDU4MGFkMmU1MmNhM2ZjMDZjOWQ=.
The API server reverses this process. When it finds the HTTP Authorization header, it will decode base64 result, read the API key ID and Secret and validate these tokens before allowing the request to be processed.
HTTP Basic Authentication is simple but for mobile apps securing the API Key is a main concern. HTTP Basic Authentication requires raw API keys to be sent over the wire for each request, thereby increasing chances of misuse in the long run.
Also it is impractical as you cannot safely embed API keys into a mobile app that is distributed to many users.
For instance, if you build a mobile app with your API keys embedded inside of it, a user could reverse engineer your app, exposing this API key, and abusing your service.
So HTTP Basic Authentication risky in open environments, like web browsers and mobile applications.
NOTE: Like all authentication protocols, HTTP Basic Authentication must be used over SSL at all times.
OAuth2 for Mobile API Security:
OAuth2 is an excellent protocol for securing API services from open devices, and provides a better way to authenticate mobile users via token authentication.
OAuth2 token authentication works from a user perspective (OAuth2 name it password grant flow):
When a user starts the mobile app he is prompted for username or email and password.
The developer sends a POST request from app to API service with the login data included (over SSL). Then validate the user credentials, and create access token for the user which expires after a certain amount of time. This access token can be stored on mobile device, treating it like an API key which allows access to API service. When the access token expires user is prompted again for login details.
OAuth2 generates access tokens that can be stored in an open environment temporarily and are secure. It is secure because the access token are generated for temporary purpose and it reduces damage potential.
The token is stored according to the mobile platform used. For Android app, access tokens can be stored in Shared Preferences and for iOS app, in the Keychain.
It depends on how you define "mobile application". Any application running on a mobile device ? Web browsing running on a mobile device ? What is a mobile device to you ?
Anyways, the general short answer, is that you can detect the device type using the User-Agent sent in the HTTP headers. All popular mobile browsers sends this. But be aware, that:
It can be spoofed (easily)
Some applications (ie iPhone or Android apps and similar) can be written in such a way, that they don't send a user agent with the HTTP requests. Best practice mandates to send the User-Agent though.
I don't know of a more reliable way to do this; and as long as stuff happens over HTTP there generally won't be any way of knowing anything about the client for certain. For mostly all the use cases, you will be alright with looking at the User-Agent.
You can buy access to User-Agent databases containing various device data, if applicable, two of such being WURFL or DeviceAtlas.