In my previous article, Using a Reverse Proxy to Protect Third Party APIs, I left you without a solution to secure the purple API key inside the mobile devices in the graphic above from being extracted by the bad guy wearing the orange hat. As promised I am going to show you in this article how you can implement a solution for it.
Rather than securing the purple API key, wouldn’t it be better not to have it in the first place or at least to make sure that if it is extracted then it can’t be used at scale by malicious actors? Well that's what a Mobile App Attestation solution is for, and we will start this article by explaining what it is. Spoiler alert: it allows you to secure your API without needing to ship any type of secret inside your mobile app or, if you already have a secret in your mobile app, it allows you to ensure that the secret can’t be used to abuse your API.
Next in this article you will learn what an Approov Serverless Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app. In the end we will give you the opportunity to download an e-book that goes into the details of implementing it.
Without further delay, let’s dive into the details of using the AWS API Gateway to deploy a Mobile App Attestation service in order to control access to Third Party APIs.
The Mobile App Attestation role is described in this section of another article I wrote, from where I quote the following text:
Before we dive into the role of a Mobile App Attestation service, we first need to understand the difference between what and who is accessing the API server. This is discussed in more 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.
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.
A great benefit of using a Mobile App Attestation service is its proactive and positive authentication model, which does not create false positives, and thus does not block legitimate users while it keeps the bad guys at bay.
Serverless is a cloud based computing model, where the cloud provider takes all the responsibility to provision and maintain the real servers on which your code will run. This model allows us to dynamically scale up and down the needed resources, like memory, CPUs, disk capacity, network capacity, etc. .
A Reverse Proxy is a type of service, serverless or not, that sits between a client and one or more other services from where the client needs to retrieve or deliver some data to/from, in any kind of content type. So the reverse proxy acts like a mediator between two parts that shouldn’t and/or don’t need to be in direct contact. You can go in more detail about what a Reverse Proxy is in this section of the previous article.
A good example of a cloud provider that has an API Gateway as a service which can be used also as a Reverse Proxy is AWS. The AWS API Gateway allows us to run code through lambda functions without needing to care about the real server running it. Instead we just need to worry about how much resource we want to use, and we simply pay for whatever we use.
Combining the serverless AWS API Gateway with their Reverse Proxy capabilities allows us to use an authorizer and a lambda function to deliver a completely serverless experience for the Approov Token check within a Reverse Proxy.
The Approov Token check is always performed before the API Reverse Proxy forwards any request to the backend or uses the cache to serve the request. This is done by leveraging the serverless capabilities of the AWS API Gateway authorizers, allowing us to use lambda functions to check the Approov Token and establish the IAM (Identity & Access Management) policies to be used by the Reverse Proxy to allow or deny the request to reach the destination service.
So the Approov Serverless is the part where an authorizer and a lambda function is used to check the Approov Token, and the Reverse Proxy is the part where the requests to the backend are made on behalf of the client, the mobile app, that has delegated to the Reverse Proxy the task of providing and securing the secret necessary to communicate with the API backend. The Reverse Proxy doesn’t expose this secret to the public. You will need to provide it through an environment variable, or for added security a secret management solution can be used, like the AWS Systems Manager Parameter Store or the open source Hashicrop Vault project. You can setup and use these solutions from within your AWS account.
First and foremost if you already have your backend behind an AWS API Gateway, you will be looking to keep any new security controls within it, thus adding the Approov Token check with only one authorizer and lambda function will be both simple and efficient for you.
The next most natural reason you might use this approach is to protect access to third party services that normally need some kind of secret to identify and authorize access to them.
For the use cases inside your own organization when you don’t own the backend you will want to protect the access to with an Approov Token check.
When you want to centralize the protection to access third party services, backends you don’t own and your own backends, this approach would also make sense.
On top of all the reasons given in this section of my previous article, we can add:
As the name says, it’s serverless, therefore your team of developers or DevOps don’t have to spend their time managing servers, configuring and keeping operating systems up to date, worrying about the application environment or the structure. The only configuration you need to do is the one of the AWS API Gateway itself, the authoriser and the lambda function necessary to implement the Approov token checks.
Caching is always a good mechanism to avoid repetitive work, since it’s known to always yield the same result, thus improving the response time of an application while saving on resource consumption.The AWS API Gateway already has a cache mechanism that’s easy to use.
The AWS API Gateway will automatically scale up to handle any number of requests to your API, without throttling them, unless explicitly configured to do so. Thus you will not need to worry about capacity to handle the incoming requests or about downtime because it’s all done automatically for you by AWS.
Further caching can be enabled if required to alleviate pressure on your backend, thus allowing it to be available to serve much more users simultaneously.
If your service is slow or unavailable, it is very unlikely to be due to the API Gateway. It’s much more likely to be due to your backend because on this you will need to configure the auto scaling policies in order for it to be able to handle more load as needed.
When using the AWS API Gateway as the gatekeeper for third party services and backends, you can leverage many features and associated services in AWS to release more time within your team of developers to spend on what matters, business functionality. Some examples of useful AWS services in this context are authentication and access control, cors, rate limiting, monitoring, logging, API version management, etc..
Another great feature is the possibility to add lambda functions to do something with the incoming requests, thus allowing you as the developer to implement your own custom logic for those situations where the native solutions are not enough or don’t fit well with your use cases.
In the AWS API Gateway at the moment of writing this the APIs are only billed for the calls they receive/process and the amount of data transferred out, but not for the incoming data. These charges can be reduced even further when the previously mentioned cache is used, but you need to account for the fact that the cache is charged on a per hour and size basis.
There are currently some exceptions to this, as you can see here. One particularly relevant example is that AWS doesn’t charge for API Gateway throttled requests when the request rate or burst rate exceeds the preconfigured limits. Another exception which should be considered is that requests for methods that require an API Key are not charged when the key is missing or invalid.
Technically the API Gateway bill can have a zero cost for zero use. For new customers the cost can also be zero provided they don’t go over the limits of the free tier in the first 12 months.
Depending on whether you are already familiar or not with the AWS API Gateway, this can be very easy to implement or a little more involved, but it’s certainly nothing that any Developer, SysAdmin or DevOps engineer cannot achieve. In fact, if you already have an API Gateway in use between your mobile app and API backend, implementation could be very simple indeed.
For a very comprehensive and detailed “how to” for creating an Approov Serverless Reverse Proxy in the AWS API Gateway, we have created this e-book to guide you through the process, no matter your level of experience and expertise with AWS.
If the When and the Why for choosing the Approov Serverless Reverse Proxy in the AWS API Gateway has ticked a few boxes in your use cases, then this is the right approach for checking your Approov Token. Otherwise you may want to take a look into another option, Securing Your API server with Approov and Cloudflare, or going with the traditional approach of doing it directly in your API backend, and for that you can visit our Github Integrations Examples.
If you are not sure yet of the approach you want to use to check your Approov Token, then please contact us to discuss your use case.
Paulo Renato is known more often than not as paranoid about security. He strongly believes that all software should be secure by default. He thinks security should be always opt-out instead of opt-in and be treated as a first class citizen in the software development cycle, instead of an after thought when the product is about to be finished or released.
