How to store API keys in Flutter

Question

If my flutter app requires a secret string to operate, say an API-key, then what strategy would prevent a malicious party from being able to extract this API-key from the published app?

I found some discussion threads on this subject, but none seem to arrive at an answer.

Use flutter_secure_storage

I don't think that works. I can use this to pass user input to Keychain/Keystore where it will remain forever safe. Unless I personally type the API key into each installation of my app, this can't be used for storing an API-key, without the API-key being in the code/assets.

Store the API key on a back-end server, only pass results to app

Well that just creates the same problem with extra steps. My Vendor API-key is now safe on my back-end server. But whatever 'key' I am using to police data requests from my back-end server, that needs to be in the Flutter code/assets.

Use a Firebase remote config

Firebase says don't do that:

Don't store confidential data in Remote Config parameter keys or parameter values. It is possible to decode any parameter keys or values stored in the Remote Config settings for your project.

So, those are a couple of ways that I think do not work. Is there actually a strategy that does work?

Answer 1

I created a platform app with a complete backend and the way I implemented the communication between the client (flutter app) and server backend as well as security is the following:

1. Clients can register and get a short term jwt to perform api calls as long as the jwt is valid. in the jwt which is not editable since its signed by my server, im providing the user id and can double check on server side if the user belongs to my app.
2. the jwt itself is saved in secure storage at the client which is meant to be used for "critcal information", but will be destroyed if user logging out, jwt expires or another account will be logged in at the specific device. the jwt itself is short termend.
3. if the short termed jwt expires at any time, the client automatically receives a new valid short termed jwt from a refresh token from my server, as long as the credentials provided are valid.
4. Hold the refreshapi token and every sensible information in your backend.
5. make sure you scope the user and its actions which can be done to your backend server.

the secure storag package is using:

• Keychain used for iOS
• AES encryption used for Android.

So my short term jwt is actually stored on the smartphone where you last logged in and wont be the same after short time or when you will change the device or log in in a different place.

---

Some more informations and personal experience

When I was deep diving into how security will work in a client to backend communication I had so many open questions and It took me really long to understand, that you can't lock your api backend to the outside. Everyone can call big companys apis if you know them just with applications like postman in the exact same way you are testing your backend code. Why im telling you this?

I invested so much time finding solutions to build a solid and secure implementation between client and backend, providing environnment variables, writing more complex code, saving critical information somewhere, put 3rd party services between the client backend communication which holds the critical information and so on. In the moment where you will save any kind of critical api or credential on the client you won't have any control. People than can do whatever they want compiling your app or any other stuff. Keep in mind: Never trust the client

You are on the wrong track If you are trying to hold the final "key/secret" at the client, posting it to your backend which needs to validate it. Forget this approach. I think many people like me at this time, who didnt yet investigate in secure applications will have the exact same thoughts.

Reading the above, the 5 steps I described earlier is a good start to bring solid security into your application. Yes it's much more work and more complex implementing it, but you can confirm, that whatever the client tries to do, the door to your backend is not unlocked by compiling the app reading some keys from your app.