Regarding Appgyver Auth system

Two questions:

  1. Is it possible to design the entire user account system using the default Appgyver Auth setup, and then “export” it and adjust as necessary for use in another third-party system? Or better, can we design it here and just have the database hosting elsewhere? Is there cross-compatibility as with some other platforms?

  2. Is it possible to add additional “account fields” to the Appgyver Auth system? For example, in a social app, we would like each user to have a username/password for login and ID, a display name (nickname/full name, etc.), an optional location tag, an optional external URL link, an About section for their profile, and of course, list fields for different kinds of text data – it’s a social Q&A app, so we’d need collections for initial questions and their answers, etc.

Much obliged.

Sorry for the long wait! Proper auth and user management is coming with our Cloud Mesh BaaS product, but in the mean time, it’s a bit limited.

Exporting users or hosting the database elsewhere are currently not supported.

There is a theoretical possibility to use the metadata field to include arbitrary user metadata, but the flow functions to do this are not exposed, plus you can’t e.g. view the user metadata field via the user admin UI.

At the moment, the hosted user management is best for small-scale trials, but we will change that with the BaaS product. :slight_smile:

1 Like

Hello Harri!

I would also like to clarify one question regarding authentication.
Currently our app uses firebase auth, which provides id tokens when users authenticate successfully. These tokens are supposed to be stored locally so that users don’t have to sign in repeatedly every time they open the app. We do save these tokens locally by using “Set to persistent storage” flow function. My concern is how secure is this persistent storage? Is it possible to access the persistent storage on the phone outside the app? Is this data encrypted in any way, and if not, can it be encrypted?

Thank you!

Currently, the storage works using React Native’s Async Storage, which is inherently not secure in the sense that an attacker gaining access to the device can retrieve the data with some effort. In the same way, someone getting access to your laptop web browser could copy a session token or cookie from some website you use.

Thus, the best way for a mobile app to deal with data security is to ensure only minimal data is stored in any persistent storage, and have any sensitive data be transmitted over APIs secured by app-specific, user-specific, backend-revokable auth tokens that only give access to the necessary data and nothing else. You can increase security by invalidating the tokens server-side periodically and then requiring a re-login.

Given the fact that you can’t have a secure crypted anything without a decryption key coming from somewhere else, persisting the token (or any other data) in a secure way on the device only is not very easy, as you need some way to get the decryption key in from “outside” the local device.

There are intermediary extra things a mobile developer could do such as always encrypting the data-at-rest and having e.g. a pin code or biometric auth fetch the decryption key from a server, but these are pretty epic features to implement – we hope to bring features such as these as something Composer makes easily available in the future.