I'm creating a web application intended for a heavy industrial setting. Would like the operators to be able to use a central tablet or computer as an interface to the application, so multiple operators would be sharing a device during a given work shift. Plenty of information on standard personal devices, but not shared industrial settings.
Question - What is the best way for web app security/authentication and what are the various alternatives?
Would they all use the same authentication session (this is not preferable, as I'd like to uniquely identify the active user)?
Obviously I could use standard username/passwords with token based sessions that expire, however, this leaves a lot of potential for account hijacking.
Ideally, they'd be able to log on very quickly (PIN, perhaps?) and their session would end when they are done.
In industrial settings, you typically want ruggedized hardware. This is fairly specialist kit, and typically much more expensive than "vanilla" computing hardware. Depending on the environment, you may need waterproof and dustproof enclosures. Google will provide a range of options. Non-ruggedized equipment will usually not withstand the harsh conditions, and is likely to fail quickly or unpredictably.
If you want to audit who made particular entries, you'll want some kind of authentication mechanism. Biometric logins - fingerprint etc. - are available on a range of devices, and will make it easy for people to log in without entering usernames and passwords (which are often shared). In this model, the user authenticates to the operating system, not the web application; gluing those together is do-able, but heavily dependent on your enterprise identity management system and the frameworks you're using for building your web application.
Another option is to use RFID cards - again, many ruggedized computers support RFID readers which can read a card or keyring style physical object. This is less secure than biometric authentication as people do share cards. Again, authentication here is at the operating system level.
The benefit of using the operating system's authentication tools is that you benefit from all the work done to secure access in a range of environments. For instance, most OSes allow you to set a policy to lock screens after a certain time out (and unauthorized users cannot override this).
Building authentication into the web application is also an option, but AFAIK biometric solutions are still a little esoteric for web apps. Username/password is easy enough in most frameworks, and if you set a short session time out, the chances that someone will forget to log out and leave the browser logged in are slim. Not good enough for the nuclear launch codes, but for a line-of-business app, probably OK.
You could also look at alternatives to username/password authentication, without using biometrics - e.g. a passcode or image recognition option ("here are 16 random images, which is your grandmother?"). AFAIK, that's not a standard feature in most web development frameworks, so you'd have to roll your own.
Thank you for posting this cool problem.
Is the device in a controlled setting, where only authorized workers can have access to it? Is the possibility of theft of the device low, as in the people who have access to it are unlikely to move it?
Is your main interest, in other words, identification and not authentication? If so, how do you quickly identify who is operating the computer without interfering with the work or making it too cumbersome to use? Do you need to identify the person in order to carry-out the work, or is having the identity merely a precaution for later audit, to answer the who did it question?
One option is to use face recognition or simply capture a photo. Other biometrics are possible such as voice and fingerprint. An id card or dongle can be passed around, has to be fished-out in order to use, and the worker has to remember to bring it. A pin or other secret can be readily shared as well. Capturing a biometric is a reliable way to identify the worker.
Can you do smart card auth? That's how we used to do it in the old days. This was circa 2006, using Windows XP. Smart Card reader was a USB device, the auth was standard windows with smart card, however I can't recall anything about the cards.
Login to the device by reading the operators smart card, then do kerb auth against the service. If kerb is too old school, you could probably turn OS auth into OIDC without too many dramas using something like Okta or Auth0.
Alternatively have the device use the same credential for all users, but get the os user name from the request context somehow.
EDIT
For some more concrete examples of this:
Here's the windows article on smart card auth: https://learn.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-how-smart-card-sign-in-works-in-windows Getting hold of the cards / card reader is not something I've got any experience with, but it's usually bread and butter for industrial sites where a user has to clock on / clock off.
Once the user is authenticated to the OS then it's a matter of use that auth context to get a web friendly auth scheme.
You could also use SAML Federation between an IdP and ADFS/AzureAD which would allow you to issue a OAuth2 access token
Okta supports can do SSO (by effectively hiding the SAML Federation) using a browser plugin: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Browser_Plugin.htm.
End result is that for a user logged in to Windows you can issue an Oauth2/OIDC access token
The web app can use standard OAuth2 access token authentication
A lot of this is nothing to do with the web app, it's all about how to take the OS auth context and use that to get something "normal" for the web app to consume.
Good luck!
Related
Building a multi-tenant application. The tenancy of the application is organizations and each organization can have multiple projects.
As user authentication, implemented OAuth based authentication and role-based authorization.
Example
Let's assume our service serves images to the user applications and naming it imagebox server.
Now a user can register with our application. First, he needs to create an organization and then he can create multiple projects in an organization.
In a project, he can create an image with the following properties
Name of the image
Description
Upload an image ( It will automatically create a URL)
The customer on imagebox server, will create App Keys. Though we need only one app key per project. Though, he should be able to create multiple app keys as well delete the previous one whenever needed.
Now customer of our image box, download the SDK from the imagebox server. They write their application over the SDK and pass the APP key.
ImageBoxClient client = ImageBoxClientBuilder.build(APP_KEY);
The client should be able to access images of the project corresponding to the API key.
Questions
Is there any difference between API keys and App Keys?
How to handle Authorization - How to restrict only N:1 mapping between API key and project, a project can have multiple API keys but a key should belong to only one project?
How to achieve authorization in the above case (restrict key to the project), if I intended to use identity management solution like Azure AD?
How to achieve authorization in the above case (restrict key to the project), using API gateway?
Assumption
From your question its not clear if the client SDK's are mobile applications or not.
My answer will be based on the assumption that they are SDKs for mobile applications, but even doing so, a lot of what I will say it's still applicable for SDKs that aren't for mobile applications.
The Difference Between WHO and WHAT is Accessing the API Backend
As user authentication, implemented OAuth based authentication and role-based authorization.
User Authentication will identify WHO is accessing the API backend, but will not identify WHAT is accessing it on its behalf, and you are thinking in using an API key to identify the WHAT part.
So 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 a genuine version of the mobile app, and communicating directly with the API backend 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 backend is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate all possible ones here.
So 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. 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 the WHAT may be one of your 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 mobile application.
API Keys
For a project, there will be a unique app key using which SDK authenticate and identify the project.
So I think you want to say here that you will use an app-key or api-key header to identify WHAT client SDK is accessing the API backend in a per project basis, and this seems to be reinforced by:
Is the API key is the right solution, then how to restrict only N:1 mapping between API key and project, a project can have multiple API keys but a key should belong to only one project.
In my understanding the client SDK will need a specific API key per project, thus if it needs access to more then one project it will need to be released with one API key per project it needs access to.
While this may be useful to filter down and identify access to each project, I want to call your attention that it cannot be trusted as the only way to restrict access to them, and I hope that by now it's easy to see why, because you have already read about WHO vs WHAT is accessing the API backend? If not please go back and read about it.
Anything that its shipped into a client SDK must be considered public, and if you have shipped secrets with it, you need to considered that they are now compromised, because an SDK can be reverse engineered by de-compile it, or a MitM attacks can be performed to understand how it communicates with the backend, and instrumentation frameworks can be used during run-time to hook on the running code, and change its behavior, and/or extract data.
Extract an API key with Reverse Engineering
You can learn how to do it by reading my article How to Extract an API key from a Mobile App by Static Binary Analysis, and see how easy it can be done.
Using MobSF to reverse engineer an APK for a mobile app allows us to quickly extract an API key and also gives us a huge amount of information we can use to perform further analysis that may reveal more attack vectors into the mobile app and API server. It is not uncommon to also find secrets for accessing third part services among this info or in the decompiled source code that is available to download in smali and java formats.
The above article have a companion repository, that shows one of the most effective ways of hiding a secret in an mobile SDK, by using the JNI/NDK:
JNI is the Java Native Interface. It defines a way for the bytecode that Android compiles from managed code (written in the Java or Kotlin programming languages) to interact with native code (written in C/C++). JNI is vendor-neutral, has support for loading code from dynamic shared libraries, and while cumbersome at times is reasonably efficient.
Extract an API key with a MitM Attack
In the article Steal that API key with a Man in the Middle Attack I show an easier way to extract an API key, or any other secret, from a mobile app, and performing the MitM attack is made easy by using a tool like MiTM Proxy:
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
Instrumentation Frameworks
A more advanced technique is to use instrumentation frameworks, like Frida or xPosed to hook into code at run-time, and change its behavior or extract the secrets from it.
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.
xPosed
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
So if your are storing secrets in the keys-tore of your device, an attacker just needs to poke around the code until he discovers the method that retrieves the secret from the vault, hook on it at runt-time and extract the secret without changing behavior, therefore staying under the radar. The extract secrets can then be sent to a remote control server, that will launch automated attacks against the API, just like if it was the WHO and the WHAT the API is expecting.
Defending an API Server
Depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones, but before I do it so I would like to leave this note:
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 allows the API server to verify with a very high degree of accuracy, that the requests are coming from WHO and WHAT is expected.
Conclusion
My recommendation is to use defense in depth, where you use as much techniques as you can afford and 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.The end goal is to increase the expertise and time necessary to overcome all defenses, to the point that the attacker may give up and move on to easier targets.
So defending an API server is a daunting task, and and never ended battle.
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 developed API in dot net. This API is consumed by different application. I have to generate a different key for each application which is consumed by this API. Can anyone please share their Ideas. This is first time i am doing such tasks.
Your Problem
I have developed API in dot net. This API is consumed by different application. I have to generate a different key for each application which is consumed by this API.
When creating an API, no matter if consumed by one or more applications you need to deal with the fact of WHAT is accessing the API and sometimes you also need to care about WHO is accessing it.
With this in mind lets clear a common misconception among developers about WHO and WHAT is accessing an API server.
The Difference Between WHO and WHAT is Accessing the API Server
I don't know if the applications consuming the API are mobile or web based, but I will do my analogy using a mobile application, and for a web application the difference between WHO and WHAT will make no difference.
To better understand the differences between the WHO and the WHAT are accessing a mobile app, 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.
Defending an API Server
Can anyone please share their Ideas.
A mobile app or a web app should only communicate with a API server that is under your control and any access to third part 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.
For an API serving a web app you can employ several layers of dense, 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.
The 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.
Summary
I think it should be pretty clear by now that you will need to use an API key for each application to identify the WHAT, and if you care about the WHO you should employ an OAUTH solution to, and then choose what defense layers you want to put in place on the API server to guarantee that you really know that the WHAT and the WHO is accessing the API server are really the ones you expect.
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 using API keys may sound like locking the door of your home and leave the key under the mat, but not using them is liking leaving your car parked with the door closed, but the key in the ignition.
Going the Extra Mile
This is first time i am doing such tasks.
So I real recommend you to read some links...
Web Apps
OWASP Web Top 10 Risks
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
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.
In the context of WCF/Web Services/WS-Trust federated security, what are the generally accepted ways to authenticate an application, rather than a user? From what I gather, it seems like certificate authentication would be the way to go, IE generate a certificate specifically for the application. Am I on the right track here? Are there other alternatives to consider?
What you are trying to do is solve the general Digital Rights Management problem, which is an unsolved problem at the moment.
There are a whole host of options for remote attestation that involve trying to hide secrets of some sort (traditional secret keys, or semi-secret behavioural characteristics).
Some simple examples that might deter casual users of your API from working around it:
Include &officialclient=yes in the request
Include &appkey=<some big random key> in the request
Store a secret with the app and use a simple challenge/response: send a random nonce to the app and the app returns HMAC(secret,nonce))
In general however the 'defenders advantage' is quite small - however much effort you put in to try and authenticate that the bit of software talking to you is in fact your software, it isn't going to take your attacker/user much more effort to emulate it. (To break the third example I gave, you don't even need to reverse engineer the official client - the user can just hook up the official client to answer the challenges their own client receives.)
The more robust avenue you can pursue is licencing / legal options. A famous example would be Twitter, who prevent you from knocking up any old client through their API licence terms and conditions - if you created your own (popular) client that pretended to the Twitter API to be the official Twitter client, the assumption is their lawyers would come a-knocking.
If the application is under your control (e.g. your server) then by all means use a certificate.
If this is an application under a user control (desktop) then there is no real way to authenticate the app in a strong way. Even if you use certificate a user can extract it and send messages outside the context of that application.
If this is not a critical secure system you could do something good enough like embedding the certificate inside the application resources. But remember once the application is physically on the user machine every secret inside it can sooner or later be revealed.
I'm currently thinking how I could protect my REST API which is used only by my mobile application from being used by other applications?
Could a API-Key be a good solution, because just me know the secret API key.
Is there a better solution?
Leon, you keep mentioning "someone else using my API with another application". So, you want to tie your API to be used only by one application? So, you don't want to give access rights to a user, you want to give them instead to an instance of your application running on the user's mobile device.
In essence: You don't trust the user!
Well, in that case you need to make sure your application is closed source, need to code your credentials into your application in such a way that nobody can retrieve them or store the credentials for it in a specially encrypted manner on the device, the decryption key for it being readable only by your application. In a way, you need to implement a form of DRM to prevent people from doing stuff with data on their mobile device. And you need to hope that nobody can reverse engineer it.
If your app becomes popular / interesting enough, count on the fact that people who are very, very good at this sort of thing will look at your application and will break your encryption before you know it. Maybe, if you put the same amount of effort into it as Skype has, maybe then you can ward them off for a while.
But ask yourself: Why bother? Why don't I trust my users? Is it really worth it to jump through hoops like this to prevent some other application from using my API?
Just lead your user through a registration process in which each app instance gets a unique key from the server (or a unique HTTP auth password) and stores that somewhere on the user's mobile device. Then, to access the interesting features in the API, require the presence of this key/password. But don't go through extreme length to obfuscate or encrypt the key when you store it locally, it's not worth it. If you every detect misuse later, you can always revoke the access rights for a particular account on the server anyway.
Use HTTP Authentication. REST is all about using the facilities available in HTTP, so the native HTTP auth should be used. With basic authentication you’ll have to use HTTPS though. If you cannot do that use HTTP digest auth or NTLM.
All of them have different strengths and weaknesses, and not every one of them might be supported by your HTTP server and client library.