I have this token that I am using to call remote rest API
I get this token from the server in the app at runtime (when user install the app)
How/where can I store this token on Android device so it will not go away,
So even if user clear the app cache or clear the app data it will stay?
So local file or db is out of the question..
Thank you
This is not recommended way but if you request external file storage permission
from user and store token as file (with encryption) somewhere outside of app storage, you can get it again after clear app storage.
However this is not recommended because when user clear app data app should reset its state, when user uninstall the app the token file is remain in user's storage as a garbage.
Also external files can be deleted by user out side of the app at anytime so you need recovery plan for such situation.
As a conclusion you are encouraged not to create such system.
If you need just user identity, check Best practices for unique identifiers to map id to token on server or something like that.
You can't achieve that without writing to external file like mentioned above. What you should do, is save the token to SharedPreferences, check if the token is there every time you launch the app, and ask the server for a new token if it's not there.
Related
I have an app, that on the first start generates a random user id and password to set up an account on my server and store them in the shared preferences.
I am looking for a way to write this data into the cloud so that if the user installs the app on a second device it will retrieve this account data and use them on the second device as well.
On iOS, this is a trivial task but I am still trying to figure out how to achieve this on Android. I tried an approach with Firestore, but it seems to be able to write to the Firebase database, the user has to log in with Firebase. I assumed being logged in to a Google Account on the device would do this, but I still get invalid permissions back when writing data.
I do not want to force the user to a separate login.
Any ideas on how to approach this task? Is it possible on Android at all?
I have an app, that on first start generates a random user ID and password to set up an account on my server and store them in the shared preferences.
If you have your own server where you authenticate the users, and you also want to authenticate to Firebase, then I recommend you check:
Custom Authentication System
I am looking for a way to write this data into the cloud so that if the user installs the app on a second device it will retrieve this account data and use them on the second device as well.
You just should never simply store the credentials in Firestore. Storing passwords in cleartext is one of the worst security risks you can inflict on your users. You should either use authentication with your custom system or use one of the existing providers, like Google, Facebook, etc.
I tried an approach with Firestore, but it seems to be able to write to the database, the user has to log in with Firebase.
It's recommended to authenticate the user in Firebase before reading/writing data from/to Firestore because you can secure your database using Firestore Security Rules.
P.S. Don't store data in ShartedPreferences because this type of data is stored locally and doesn't persist application uninstalls.
We have apps developed for both Android and iOS which interacts with devices via BLE and uses a Spring boot backend server in which they have registered and logged in. They can log in with the same account on either Android or iOS (obviously). During the interaction we can get codes that the user may need in the future. To handle that we currently do this:
Android: Encourage the user to write the code down. Use the users login information (username/password) to generate a symmetric key which is used to encrypt data which is then sent to and stored in our server. That way, only the user can retrieve it and decrypt it. Drawbacks would be the way we generate the key in itself and the obvious fact that a user that has forgotten password/changed password cannot decrypt the data anymore.
iOS: Encourage the user to write the code down. Then store it in KeyChain with the kSecAttrSynchronizable attribute so it can sync to iCloud KeyChain. That way the user should be able to get it on any other iOS device. Obvious drawback is that if the user chooses to switch to Android then the code cannot be retrieved there.
Is there anyway we can store sensitive user app data for both platforms? We could store it in our server but since we want the users to encrypt it themselves (so we can't see the content of the data) we need some unified way. There is no magic Spring boot feature to store "encrypted user data" for a specific user which only that user can retreive?
Have thought about using Google Drive and store it in the hidden app folder. But I'm guessing that wont work with an iOS app that uses the Google Drive SDK?
EDIT
Just to exemplify:
A user buys the device and connects it to its Android app. The user then changes the reset code of the device which is what would be needed if the device was ever "factory reset" (of course not factory, but cleared). When that is done we encourage the user to write this code down/remember it. Then lets say the the user loses the Android phone and buys an iPhone. He logs in to the exact same account but now might need to reset the device in order to start using it again. If that code could have been stored somehow using the account (or using the users google account or anything) then he wouldn't have to remember it.
I could not find this anywhere, but..
How does Firebase provide security on the persistence of user sessions in Android? So, a user logs in, and he can now perform certain actions corresponding to his privilege, obviously the auth token and other data is hold somewhere for the android app to send to firebase. Where? How is security enforced?
Thanks
Android provides the security, and Firebase doesn't really have to do anything special. On Android, each app is provided a dedicated per-app local storage space that only the app process itself can read and write. No other apps can access this. This is where the token is stored. According to the Android documentation:
App-specific storage: Store files that are meant for your app's use only, either in dedicated directories within an internal storage volume or different dedicated directories within external storage. Use the directories within internal storage to save sensitive information that other apps shouldn't access.
Any app can use its own dedicated space to store data securely. This is what the Firebase SDKs use.
What I can say from my experience with firebase auth store current login user info
in share preference i.e. APP_SHARED_PREFERENCES inside that here is column for firebase auth com.google.firebase.auth.api.Store.{some random string} inside that you can find key value pairs as follows
Key com.google.firebase.auth.FIREBASE_USER value > current login user info
key com.google.firebase.auth.GET_TOKEN_RESPONSE value > token value for user
you can find this using this library
for debugging database in debug mode
I'm developing an Android application that needs to backup (and restore) some data stored in an sqlite database to (from) google (or gmail). But I don't have a clue about where to start. I read the backup guide in the Android documentation. But that's not what I need since the backup operation in that way might not be taken immediately, and it needs the device user to turn on the backup option in "settings->privacy".
I need a way that first authenticates the user's account (already on the device) using OAuth or OAuth 2.0, then after authentication, the app sends the data to gmail and can later get it back from gmail to restore it to the device.
How can I implement this?
Another question: when I send the data to gmail, what format should i use? The database file, XML, or something else?
I'm looking for something like the Keychain on the iPhone, but for Android development. Something that gives me the capability to save small key-value pairs that are persistent and unchanged even if the user reinstalls the application.
Is there something like that? Can I use the standard preferences that way?
I would like to achieve a behavior similar to the way it works with games on a PC - writing the save files to another folder so that after deletion and reinstallation the save files are not lost.
Edit:
The bounty ran out without somebody mentioning the accountManager. I just stumbled over it. Would that be a method to achieve the behaviour described by me?
You you use storage on the SD card like Michael Cramer stated ( Let the user know you are storing data :-) ). The data on the SD card is not deleted when the app is removed.
You could on the other hand use a server which stores all the details which can be downloaded as and when required and instead of using a user name use the IMEI of the phone which is unique. That way even if the user reinstalls the OS he will still be able to refetch the settings.
for getting the IMEI you may refer : How to get the device's IMEI/ESN programmatically in android?
You have the real thing here:
By integrating Smart Lock for Passwords into your Android app, you can
automatically sign users in to your app using the credentials they
have saved. Users can save both username-password credentials and
federated identity provider credentials.
Integrate Smart Lock for Passwords into your app by using the
Credentials API to retrieve saved credentials on sign-in. Use
successfully retrieved credentials to sign the user in, or use the
Credentials API to rapidly on-board new users by partially completing
your app's sign in or sign up form. Prompt users after sign-in or
sign-up to store their credentials for future automatic
authentication.
https://developers.google.com/identity/smartlock-passwords/android/
Since Android & iPhone-like phones will normally run with a data plan, I would suggest that you save your key-value pairs into a centralized server. When the app goes through the uninstall, followed by an install process, just resync it with your server.
Yes. Preferences are persistant and will survive a normal application upgrade.