I don’t mind at all.
If you are keeping the refresh token in the client then it will be available to be stolen. Refresh tokens must be kept on the server side. When using tokens I personally prefer to refresh them on each API request. In other words an issued token last as long its used for the first time, but this isn’t enough to prevent an attacker from exploiting and abuse your backend, no matter if using cookies or token based authentication/authorization.
For a traditional web app requests (no Javascript) I prefer to use cookies with the HttpOnly flag set to not allow Javascript to access them and the Secure flag set.for them to only be sent in HTTPS connections. I also harden its usage with other flags, that you can read more about in the Mozilla docs at Restrict access to cookies.
For mobile apps you are better to use some secret, be it in whatever form you choose, like a JWT or an hashed string. Cookies on mobile apps can be used but they will not give the same guarantees of a browser.
Keeping a secret private in the client is where things become very tricky, because in a web app you just hit F12 to open the developer console and then you search and extract it. On a mobile app you have a lot of open source tools and methodologies to help you to extract secrets used to access backends.
This morning I replied to a question in Stackoverflow where I go in more detail on the steps to secure a secret in the mobile app:
On my reply I address to the following topics:
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.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
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.
On this article you will learn how to use the Mobile Certificate Pinning Generator free tool to easily generate your Android and iOS configurations.
How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Frida is a very powerful tool and when used by a skilled attacker it will allow him to even hook to your app code to extract any secret from it without the need to disable pinning to perform the MitM attack. The attacker only needs to figure out the name of the function that uses or retrieves the secret in order to hook on it at runtime and extract such secret. To find the name of the function the attacker will statically reverse the mobile app binary and read your source code, even if the code is obfuscated.
Hands-on Mobile App and API Security - Runtime Secrets Protection
In a previous article we saw how to protect API keys by using Mobile App Attestation and delegating the API requests to a Proxy. This blog post will cover the situation where you can’t delegate the API requests to the Proxy, but where you want to remove the API keys (secrets) from being hard-coded in your mobile app to mitigate against the use of static binary analysis and/or runtime instrumentation techniques to extract those secrets.
We will show how to have your secrets dynamically delivered to genuine and unmodified versions of your mobile app, that are not under attack, by using Mobile App Attestation to secure the just-in-time runtime secret delivery. We will demonstrate how to achieve this with the same Astropiks mobile app from the previous article. The app uses NASA’s picture of the day API to retrieve images and descriptions, which requires a registered API key that will be initially hard-coded into the app.
At the end of the day your backend needs to know with a very high degree of confidence WHAT is doing the the request, not only WHO is in the request. Think of the who as the user on which the request is being done and think on the what as the thing issuing the request. is it a genuine and unmodifeied version of your app or it’s the request being made by a bot, a tool in the likes of Postman , a cURL request, etc.. For your backend to be protected against being abused and exploited it needs to have a very high degree of confidence that the requests are only from trusted clients, aka you app, not any other origin, otherwise is like closing you home doors and leaving the windows open.
If you want to learn more about API and Mobile security I invite you to read some of my answers on Stackoverflow:
https://stackoverflow.com/users/6454622/exadra37?tab=answers&sort=newest
