We Keep Coding

What are the best practices for implementing API security with a publicly available mobile application without user authentication?

Context
I'm currently in the works of creating a public mobile application.
This application will be made available through the App Store and Google Play Store.
The user will be able to perform certain actions in the application, which will then be posted to an API.
The application will be made with Xamarin Forms.
Question
I want to secure this API to prevent anyone other than the App from making any post requests.
From what i have read the best way to go about this would be to implement an OATH2 flow.
However; i wouldn't like for a user to have to sign-in or register to any type of service.
How would i go about validating the post requests that come into the API and make sure that it's not someone that is impersonating my mobile application?
Things i have thought of:
Api-keys or clientsecrets. As it seems there are pretty easy to extract from a mobile app.
Certificate validation. (Couldn't find much on this for mobile client - server architecture)
Generating some type of checksum over the contents that i can validate serverside. However the code for this would have to be available client side or there would have to be an endpoint providing the checksum. But this would just move the problem imo.
?
Any and all critic and feedback is welcome.
i do apologize if there's anything obvious that i have missed during my research on this matter.
Thank you for your time.

Check the following for android: https://developer.android.com/training/safetynet/attestation
The SafetyNet Attestation API provides a cryptographically-signed attestation, assessing the device's integrity. In order to create the attestation, the API examines the device's software and hardware environment, looking for integrity issues, and comparing it with the reference data for approved Android devices. The generated attestation is bound to the nonce that the caller app provides. The attestation also contains a generation timestamp and metadata about the requesting app.
For iOS, you can check the: https://developer.apple.com/documentation/devicecheck
As mentioned in the documentation, non are foolproof and should be joined with other security measures, but it's better than nothing nonetheless.

The Difference Between WHO and WHAT is Accessing the API Server
From what i have read the best way to go about this would be to implement an OATH2 flow.
OAuth2 only identifies who is in the request, not what is doing the request.
This is a common misconception among developers of any seniority, therefore I will link you to an article I wrote that has a section dedicated to explain this. 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.
Your Questions/Affirmations
I want to secure this API to prevent anyone other than the App from making any post requests.
And about GET request?
Depending on the data your mobile is asking to be delivered by the API server, the GET request may have the same degree of importance in terms of security then any POST request.
Let's say you app is doing GET requests to get sensible data like PII(Personal Identifiable Information), then without them being protected you are just opening your API server to be easily abused by attackers, and this results in the so called data breaches that can have a huge legal and financial impact for the business and their customers. For example in Europe with GDPR a data breach will have huge fines, specially when they conclude that the API was not properly protected to avoid automated data extraction.
Anyone can learn how to perform a MitM(Man in the Middle) attack to see how the mobile app does the API requests in order to automate them. I wrote the article
Steal that Api Key with a Man in the Middle Attack that illustrates how easy a MitM attack can be done:
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
However; i wouldn't like for a user to have to sign-in or register to any type of service.
Well then you are left with only one way of protecting the API request, and is to know what is doing the request, and now you bought yourself a very hard problem to solve, but not an impossible one.
Your Solutions
API Keys or Client Secrets
Things i have thought of:
Api-keys or clientsecrets. As it seems there are pretty easy to extract from a mobile app.
They are indeed very easy to extract, but you can make them harder(but not impossible) to extract by static binary analysis as I explain in the article How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
Spoiler alert is that the best way to hide secrets from the above article is by using the JNI/NDK interface to hide them in native code:
Using Android Studio 2.2 and higher, you can use the NDK to compile C and C++ code into a native library and package it into your APK using Gradle, the IDE's integrated build system. Your Java code can then call functions in your native library through the Java Native Interface (JNI) framework.
Well now you just use a MitM attack to extract them and we are back to square zero? Well not exactly, because more layers of defense you apply, more the attacker needs to peel and be willing to spend the time on it, but much more can be done to upset them.
Certificate Pinning
Certificate validation. (Couldn't find much on this for mobile client - server architecture)
You can't find because certificate pinning is usually only done by the mobile app as I show in the article Securing HTTPS with Certificate Pinning:
In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.
In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.
So why not doing the same sever side? Well because once the app is release anything on it is public, therefore the certificate private key you would to ship with the app to allow the API server to pin against would be easily extracted with static binary analysis or during runtime with an instrumentation framework 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.
I can imagine you now looking where is the link to the my article with an example of using Frida? Sorry, but I don't have yet an article with a Frida example :(
Digitally Signing Requests with HMAC
Generating some type of checksum over the contents that i can validate serverside. However the code for this would have to be available client side or there would have to be an endpoint providing the checksum. But this would just move the problem imo.
Yes you are correct, the problem would have to have the code in client side, but having an endpoint providing the checksum would only move your problem into two backends, because then you would need to ensure that the checksum endpoint would only sign request from your mobile app ;)
HMAC:
In cryptography, an HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and the authenticity of a message.
Other Solutions
How would i go about validating the post requests that come into the API and make sure that it's not someone that is impersonating my mobile application?
As I said before you should not limit this to POST requests, instead you should validate that any request to the API server is indedd from *what you expect, your genuine and untampered mobile app.
Android SafetyNet
This is often the one recommended, and is a very good starting point, but it's not designed to be used as a stand-alone defence, as per Google own words:
The goal of this API is to provide you with confidence about the integrity of a device running your app. You can then obtain additional signals using the standard Android APIs. You should use the SafetyNet Attestation API as an additional in-depth defense signal as part of an anti-abuse system, not as the sole anti-abuse signal for your app.
You can read my answer to the question Android equivalent of ios devicecheck for a more detailed explanation for what you need to pay attention for when implementing SafetyNet.
iOS DeviceCheck
Until recently the device check was very limited in is usefulness, but now with iOS 14 they also the app test feature to sign the requests sent to the API server, but it still have some limitations, but I have not had the time to full explore this new feature thus I will not be able to give the same detailed explanation I gave for what to watch for when implementing the iOS device check, but I can recommend you this article:
It’s important to know that App Attest is not a “is this device jailbroken?” check, as that has been proven over and over to be impossible to perform. Instead, it aims to protect server requests in order to make it harder for hackers to create compromised versions of your app that unlock premium features or inserts features like cheats. Note the word harder: as jailbreakers have physical access to their devices, nothing will completely safeguard you from fraud in this case.
If you have a large user base, Apple recommends you to gradually roll this feature as requests to attestKey are rate limited. After carefully rolling it out for existing users, you can guarantee that it will only be called for new users.
So while this is a very good improvement from Apple it's rate limited, therefore care must be taken in what requests we decide to use it and how frequently the attestations are performed.
Mobile App Attestation
This is a concept that you can build on top of the Android SafetyNet and iOS device check solutions, and you can read my answer to the question How to secure an API REST for mobile app? in order to understand more about how the Mobile App Attestation concept works. You want to read about it in the section "A Possible Better Solution".
Do you want to go Going 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.

Identity Server(OAuth2) implementation with integration to legacy systems(Forms Auth, ADFS,AD)

We are currently building a RESTful API(.Net Core, IdentityServer 4, EF6). We have released an MVP version of it.
It also references a WCF service. This WCF service orchestrates all other calls to other internal (Legacy systems) and other integration components.
(Possibly wrong) Overview diagram of the implementation is as follows:
One of the main things we are stuck with is figuring out how to integrate different authentication and authorization systems using Identity Server...
Particularly internal service to service calls. Do we use the same IdentityServer to perform multiple functions?(public consumer authorisation & authentication AND internal service-to-service authorisation).
Traditionally we have used different WCF security configurations (Transport, TransportWithMessageCredentials...and so on), adding Forms, AD, ADFS and Service Accounts. We need to be sure we are making the right calls for making a reusable IdentiyServer implementation.
In short, Our challenge is how do you perform internal service authorization?
Is it good practice to have a central Identity Server implementation that handles both public facing requests and internal (multihop)service-to-service authorization?
Do you recommend splitting and having separate identity servers for internal service-to-service authorization from those that handle public-facing API requests?
Or do we even go further as to split and create a different identity server for each application use case?

Here are my thoughts on a solid implementation plan.
Is it good practice to have a central Identity Server implementation that handles both public facing requests and internal (multihop)service-to-service authorization?
Reasons to have shared implementation:
Simpler Solution
Reasons to have separate implementation:
Different security requirements for external vs. internal users/clients
External Outage wouldn't impact internal users/clients
Recommendation:
In the short term use an implementation that will service both with the goal
to split them out into External and Internal focus areas.
Do you recommend splitting and having separate identity servers for internal service-to-service authorization from those that handle public-facing API requests?
Recommendation:
Long term yes. See above as to why.
Or do we even go further as to split and create a different identity server for each application use case?
Recommendation:
No, creating an separate identity server for each client/use case would be harder to manage in the long term. You would create separate clients for each application/scenario. (i.e. Mobile Client, MVC web site, Internal Server to Internal Server, External API/Service to Internal API/Service [Think of B2B interfaces])
You will want to learn about the client types and how to allow extension grants, which is when a clients credentials to be used when a direct API call needs to call a secondary API as the user.

First off I would say you are going to have to bang your head on the wall a lot.
I think an ideal situation is where you only support one Identity Provider such as Active Directory. Microsoft would have you believe their solution is easy but it is not. That is why if you have to support a legacy Identity provider as well as a new system in parallel you will suffer more.
A secondary solution would be to keep the legacy Identity Provider system and implement the new API through it. I guess it must be a custom solution that is hosted on your own resources. That has the disadvantage to come with no built in capabilities and every new need must be built from scratch.
Honestly if you can isolate the legacy (or remove it) from your new system you will get huge benefits long term for maintenance and malleability.
I would look at code samples before making a decision. Better know deal breakers before spending weeks in any direction.

Here's my point of view for above problem
A Separate Identity Server for internal service
There are more pros in separation of identity server for internal service i.e.
Outage & Configuration changes in future won't affect consumers.
For Testing Purpose, a separate identity server is best if you are trying to support legacy applications
New Server has long term benefits & Security Enhancements.

How to Grant Angular Authorization to my REST API Calls for Mobile App

I have a C# Azure Web API backend where data is retrieved from a front-end Ionic Mobile App (which is basically an Angular App)
The authorization of users is done via Ionic's cloud service, so they handle the heavy lifting of registering users via FB, Twitter, basic (username/password).
My question is, when I go to call services from my backend API, how can I make sure someone just doesn't read a hardcoded username/password inside of the internal javascript code to access the backend data?
I know it's pretty far fetched, but is there anyway for the API to know the request is actually coming from the app (Android and iOS) and not just from someone trying to insert data and comments from a web browser that is unauthorized?

Since you're calling the API from JavaScript that is available for end users, you can assume that your JavaScript and all the logic/credentials contained within are accessible to all.
There are fairly secure ways around this, and FB/Twitter and their ilk have implemented it (using OAuth). Essentially, on passing credentials to the API, a token is generated, which is then used for subsequent calls to the API instead of the credentials.
You can avoid people randomly firing off 'unauthorized' requests using nonces which are generated when you render the form, and can be used only once to submit the form in question. You can then time-limit the validity of the nonce on the API end. Unfortunately, it's not foolproof, but this will limit the damage of any sort of 'brute-force' attack that you might get.
Again, with any shared 'secret' (that would guarantee the origin of requests), you have to assume that anyone with enough willpower will be able to extract it from apps, thus any method you implement here will be 100% foolproof. Probably the best you can do is have a shared secret generated for each user on each device.

Short answer: you can't.
Long answer: you can (and must) validate the behaviour of a client but not the client itself.
For example we can take a look on Pokemon Go: after a few hours there were bots able to play, after a couple of weeks Niantic started assuming Machine Learning software engineer and encrypt its API using unknown6 algorithm for stopping the bots, but after a few days of hard working the bots came again online.
You can use all the secure method of this universe (whit an high expense) but if someone (that have good knowledge of software engineering) want emulate your client at the end I will reach his objective

How to force third party service respect the security?

I have to come up with an integration process to allow existing system to use external data providers. The system is a medical timetable web site, using ASP.NET MVC, that allows the patients to schedule their appointments to doctors.
As far as I go you can see on a figure below:
All the providers must expose my contract ISuperIntegration which will be develop by me. I won't be developing External service 1 and External service 2, they will be developed by other companies.
Here the issue comes: basing on the concept of that I could require the way providers should setup their services to communicate with my website properly, I want to forbid for another third party clients consume "External Service 1" and "External Service 2", Or at least make it difficult to do that.
Here is a list of stuff I am setting:
ISuperIntegration interface. It contains operations related to my domain such as GetSchedule, GetDoctors and so on.
Transport protocol. I don't want it to be complicated so I'm thinking about using HTTP.
And could define some general recommendations but they could be easily avoided.
At the moment I'm thinking of using HTTPS with certificate authentication. It would require the implementer to setup their infrastructure so my web site could properly consume the data.
If I would go with basic HTTP, the implementer would just leave their service to be easily consumed by anyone else, which I don't want.
I hope my question is clear. Will be happy to give any other explanations you want.
I'll really appreciate any your responses, commits. Thank you!

I'd always use HTTPS for things like this. Let's just say that's the cost of doing business. You simply cannot have anyone with a sniffer grab that kind of traffic out of the sky. There's a reason why all banking etc. use HTTPS for things that should be secure.
Apart from that, web services have pretty standard mechanisms for security, I'd recommend looking at OAuth over HTTPS. There are plenty of implementations for that.
If your talking about basic web sites, I'd use a standard security mechanism as well like group based security (which boils down to a username + password). Again, there are plenty of implementations for that.
Basically my main word of advice is: don't go inventing stuff when it comes to security. If you're not an expert, you're probably going to get it wrong, and end up with something that can be intercepted by a third party or (much) worse.

You have several options:
Basic authentication over HTTP.
PRO. Easy to implemet
CON. UserCredentials was going in clear text throuh the network
Implement WS-Security with WCF. For example, they can sign their requests.
PRO. Easy to implement with WCF
CON. Java clients can faced with problems
You can force clients to use HTTPS.
CON. You should setup your web server.

You are like Oracle, they want people to develop in Java language but they also want to forbid competitors to run the Java compiled code on non Oracle's virtual machines, or at least make it difficult to do that :)
So you can do the same by protecting your interface with patent or copyright law. However, I doubt that it is patentable or copyrightable :)

Considering the privacy sensitivity of the data, IMHO it must be encrypted while in transport. Hence HTTPS not HTTP.
Authentication of your service to those providing services to you: well essentially it's up to them, not up to you who they expose it to, similarly how they want it protected is their call. Now assuming you do have a way to make them do the right thing...
Client certificates aren't that expensive nor prohibitive in setup to get up and running. But you do need to register the client certificate (every time it is renewed!) with the server in order to get the needed authorisation (just recognizing it's a valid cert isn't enough: anybody can apply for a (validly signed) certificate ...) .
But all that is relatively painless and rather well documented around the web, and it can be done on almost any platform of choice.

As several people mentioned these earlier you can't guarantee that those external companies will expose your service with specific security settings, it's up to them.
If you are responsible for developing MVC application and WCF service you can only force someone to use specific security settings on the layer between your WCF services and those External 1 and 2 providers.
Btw, here is a good tutorial that can be useful if you want to improve your knowledge about how to configure WCF security.
How External Services expose your service it's up to them. Just image that this is normal web 'proxy' behavior.
Maybe the architecture which your company adopted it is not the best for this solution

Secure Webservice best practices

I’m building a webservice and having some troubles witch option I should choose. Therefor I was hoping someone could point me in the right direction. I found many articles but none of them have more or less the options then I want.
What I want the webservice to do:
Client should get a WSDL derived from the ASMX file. Within that service there is one unauthenticated webmethod called “Authenticate(string Username, String Password)” that returns a custom AuthenticationSoapHeader. The AuthenticationSoapHeader is exactly and preferably same as the System.Web.Security.FormsAuthenticationTicket class that is used in the webapplication.
http://www.codeproject.com/Articles/4398/Authentication-for-Web-Services-using-SOAP-headers
http://www.codeproject.com/Articles/27365/Authenticate-NET-Web-Service-with-Custom-SOAP-Head
I’m thinking of using the articles above to implement this and changing the username password combination for a ticket that will be encrypted including a datetime stamp to expire the ticket. My questions.
Would this be considered a best practice? If not, what better option do I have.
Is using WSE3 “Microsoft Webservice Enhancement” necessary?
Is WCF a better option if your kinda new to webservices?
The soap requests go over Https SSL and do not need further encryption on the client side. Thank you in advance.
Best regards,
Danny

I can't answer all these questions, but I can answer a few: IMO WCF is all you need as a tool set for this project, based on your description. WCF has a number of different flavors (http, TCP, etc.) and each has several different options for how you implement security.
WCF has options for user/pwd authentication, or you can construct a custom method, or you can construct a Login() function that takes a UserID and Password as parameters, returning a boolean. There are also options that allow you to authenticate BEFORE the main program receives the request. That's what the built-in UserID/Password authentication does.
If you implement SSL on the host, assuming you're using an http-centric binding, you won't need anything on the client side for encryption as the WCF software will take care of that, once you have both the Host and Client software configured properly. In effect, your WCF client app will behave like a browser, handing all the nasty cert stuff under the covers.
WCF also lets you a) run your web service as a stand-alone windows service (called "self hosted"), or b) allows you to configure your web service behind IIS, which has some advantages. WCF will also provide a WSDL for your clients if needed.
There are some other nice things about WCF; if 10,000 concurrent users hit your web service at 8 am on Monday, WCF automatically queues the requests it can't handle, processing them in order as it can. I've slammed our testing web service with numbers like that, and the program never broke down, processing >150 logins and file uploads / second. WCF is also works fine with Java, iOS and Android.