How to correctly secure my api and provide authentification?

Question

I need to secure my rest apis. They are exposed to some external website backend partners as well as to a companion mobile application.

I have made a lot of readings about apis keys, jwt, oauth, openid connect but I am still confuse about how one should protect nowadays his apis...

The companion mobile application should be the unique external application to call my apis. It should provide anonymous access to user and also authenticated access. When a user is authenticated he could have an update access to his data.

So I have been told that my mobile application should use Oauth2 with PKCE : but as far as I understand it, this could only be applied to secure the authentication of a user from a mobile application.

So my questions are :

1. how to provide public access to my apis only through the mobile companion application and the external webserver backend ?
2. how to handle anonymous (unauthenticated user) consumption of the apis?
3. how one could then authenticate himself : using a token for the application and a token for the user ?

Here how I use PKCE to limit access to my API only to the mobile companion application :

Answer 1

Before I try to address your questions I would like to make clear the distinction between WHO and WHAT is accessing an API server.

WHO AND WHAT IS ACCESSING THE API SERVER

The WHO is the user of the mobile app that you can authenticate,authorize and identify in several ways, like using OpenID or OAUTH2 flows.

OAuth2

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.

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. OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.

Now you need a way to identify WHAT is calling your 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 your genuine mobile app or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

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 and some go the extra mile and compute it at run-time in the mobile app, thus becomes a dynamic secret in opposition to the former approach that is a static secret embedded in the code.

YOUR QUESTIONS

1. how to provide public access to my apis only through the mobile companion application and the external webserver backend ?

For the Webserver Backend

In this case the WHAT is not in the client side, thus you can use certificate pinning between the Webserver backend and the API server to guarantee that the API server can trust the incoming request is from a trusted source.

Certificate Pinning

Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.

For the Mobile App

In this case the mobile app is running on the client side, thus will need a secret to identify WHAT is accessing the API server and you can learn more on this series of articles about Mobile API Security Techniques how API Keys, User Access Tokens, HMAC and Certificate Pinning can be used to protect the API and how they can be bypassed.

Reverse engineering a mobile app binary is easy

The truth is that anything running in the client side can be reverse engineered easily by an attacker on a device he controls. He will use introspection frameworks like Frida or xPosed to intercept at runtime the running code of the mobile app or will use a proxy tool like MiTM Proxy for watching the communications between the mobile app and the API server. Normally their first step in reverse engineer a mobile app will be to use the Mobile Security Framework to reverse engineer the binary of you mobile app to extract all static secrets and to identify attack vectors.

Mobile Security Framework

Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.

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.

MiTM Proxy

An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.

So now what... Am I doomed to the point I cannot protect my API server from being abused??? No quiet so... hope still exists!!!

Possible solutions

To solve the problem of WHAT is accessing your mobile app you need to use one or all the solutions mentioned in the series of articles about Mobile API Security Techniques that I mentioned above and accepted that they can only make unauthorized access to your API server harder to bypass but not impossible.

You can use WAF or UBA solutions to try to identify and block abuse on your API, but this approach causes false positives, therefore requiring some relaxed rules and constant monitoring to ensure that genuine users don't get blocked of using the API.

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.

A better solution can be employed by using a Mobile App Attestation solution that will enable the API server to know is receiving only requests from a genuine mobile app.

Mobile App Attestation

The use of a Mobile App Attestation solution will enable the API server to know WHAT is sending the requests, thus allowing to respond only to requests from a genuine mobile app while rejecting all other requests from unsafe sources.

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.

So this solution works in a positive detection model without false positives, thus not blocking legit users while keeping the bad guys at bays.

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.

2. how to handle anonymous (unauthenticated user) consumption of the apis?

So here it seems that you are only concerned by WHAT is accessing your API, thus you need to decide what solutions you want to use from the ones I mentioned for the question 1.

3. how one could then authenticate himself : using a token for the application and a token for the user ?

Yes you should always know WHAT and WHO is accessing your API server. So for the WHO, the user, I recommend to go with OAUTH2 or OpenID Connect, and for the WHAT, the mobile app and the webserver, you just need to choose the solutions you want to use from the ones I mentioned for question 1.

CONCLUSION

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.

Answer 2

1. how to provide public access to my apis only through the mobile companion application and the external webserver backend?

In short terms: You can't.

What you can do is using an obfuscated serialization format, wrap everything in encryption and hide the application key somewhere deep in the binary code. But at the end of the day, as long as an attacker has access to your applications executable code, it will always be possible to reverse engineer it to the degree, that it's possible to create a faithfull emulation of the application's communication with your server.

2. how to handle anonymous (unauthenticated user) consumption of the apis?

Allow access to the API only after user authentication.

how one could then authenticate himself: using a token for the application and a token for the user?

Again, if the users have access to the applications executable, it'll always be possible to extract the application's "token".

In general you can only authenticate actors on a network, not the "gear" the actors are using.