I am making an expo application that has some user authentication features and I am trying to find a way to store the access token persistently. I have come across some library such as Asyncstorage and expo-secure-store. But I have some concerned about choosing between each of these two.
Asyncstorage --> I understand that it is an unencrypted, persistent data so I believe it means that if I want to store the token here securely, I should encrypt the token with some encryption method before store it into the storage.
expo-secure-store --> I take it that it stores that data in an encrypted way which make it more secure than bare Asyncstorage.
However, in my application, I also planned to use Redux for state management and I thinks that Asyncstorage might work with it. Based on this, should I use Asyncstorage to store my tokens or should I use both of them for different purposes or do you guys have any idea on how this will works out? Thanks!
Related
I'm making an online quiz web application with Vue js, and .NET Web API. I have JSON Web Token Auth and pass the token in local storage, also I get all my questions and answers from my API and use vuex-persistedstate to keep my state when refreshing and switching routes. I store my state in the sessionStorage but realized that this is not a good idea since I have my answers and auth token there and anyone could just go to sessionStorage and see everything. Is there an alternative place where I can store my persisted state so it is not accessible by the public users of the quiz application?
Not really, if you store it on the front end, you will have it exposed at some point.
The JWT token is fine since it's meant to be public anyway (and not dangerous by itself).
As for the possible state that you do have there, you may consider fetching it only when needed.
I mean, if it's some kind of quiz thing where people need to guess it (and you don't want them to find that one out).
If it's your "regular data" that is available after a successful auth, then keep it there, no specific issues with it. You need to have it at some point and it will not get hacked under normal conditions.
I'm building my first 'bigger' web-app (only for learning purposes & my portfolio) with the vue.js-framework. I want to implement (for the fist ever time) the possibility to login using Google's API. My question is: where would I 'store' the user-obj? It should contain information like the user-id, name, email, ... . Would I store that obj in a Vuex store in my case? Or do I not even need to store such an object as the API provide all these information?
Well, it totally depends on the needs of your project and the information that is being stored.
If the information being returned in your user object doesn't contain any sensitive information that can be used by potential hijackers to steal other information then you could always store it in local storage, cookies or runtime variables in your code. Normally, vuex store is used for manipulating the local storage. This really helps when you are accessing the data from local storage via multiple components or nested components.
But if you have sensitive information being returned from the authentication authority, like the user id or user hash string then you might not want to store them in your local storage.
Additionally, you should only use this when:
You want to keep a track of user details even when the user closes and re-opens the browser
Passing the data set from one component to all other components is not really feasible
You need to keep the state of the data set synced in all components, so if it changes in one place, it will auto-reflect in the other place.
You need to frequently access the same dataset and it doesn't really change often, so as to avoid multiple api calls to back end server.
One scenario, I can think of is of the JWT token authentication. If you're not familiar with this approach, we usually authenticate the user and store his token in the local storage via vuex and all the api calls in all the components and views start using this same token as bearer token in the requests. When the token expires a new token is fetched and updated in local storage and the change is automatically reflected in all other places.
So it makes sense to check the needs of your project/code. If your project demands the use of the returned user object and it's safe to store it, please go ahead by all means!
React Native - : How do I delete asyncstore when the application is closed.
Or What other method can I log in?
UseState in App.js is safe ?
AsyncStorage is an unencrypted, asynchronous, persistent, key-value storage system that is global to the app. It should be used instead of LocalStorage.
If you don't wan't to persist the user data, probably you don't even need to use the AsyncStorage.
Normally AsyncStorage is used to store the user token and other info from the login information to keep the user logged in (unless they logout manually). If you don't want this behavior of a persistent storage, you can keep the usertoken in a local state of the application. This way, once you close the application, the local state will reset and the token will also get deleted, when the user access your application, they will have to login every time to use the app.
If this is something that you are looking for, you can look for maybe the react-context apis or redux reducers to store the login info. If you want to go with a persistent storage option, you can opt for AsyncStorage.
You can save data to AsyncStorage with
AsyncStorage.setItem('#storage_Key', value)
And delete the data with
AsyncStorage.removeItem('#storage_Key', value)
You can read more about the AsyncStorage at https://react-native-async-storage.github.io/async-storage/docs/usage
Or you can choose react-native-keychain or react-native-sensitive-info which is more secure than using the AsyncStorage option.
I’m building a react native app that will interact with APIs that I also write/manage. I have found Auth0 documentation for implementing this flow, but I’m not sure on where/when to save the tokens. I want to be sure I nail this step, because I feel like it has the potential to reduce the security of the flow by a great deal if I don’t do it correctly.
Here is the flow as I understand it (no error handling, only happy-path for sake of brevity):
A user enters the app for the first time, or is not already logged in
They log in using the Auth0 web-login-thingy
I receive a token
I can use the token to authenticate with my API
Questions:
Do I store that token? I don’t want my users to have to log in every time they use the app. If I do store the token, where do I store it?
If I’m not storing it, what do I do? Do I ping an authentication/authorization endpoint with Auth0 every time they open the app and get a new token?
Say I am storing the tokens, if I'm using the ID token for user data, should I be hitting the API again regularly to keep it up to date? Only when the user opens the app again? Not until they trigger a change in the app?
Instead of using the ID token for user data, should I just use that to get the user's ID and ping my database for user data?
I have the basics of this flow, and I'm able to sandbox it, but I want to start applying production-ready app logic to this flow and that's where I'm stuck. I’m a little lost here, so any help is good help.
Thanks!!
Here's a brief answer to your questions when using Auth0:
Yes! you store it, the most secure way to store the token is in your device's local storage, that way it is not kept either in application's state or in a global variable.
2&3. See above, but to add more information, you can configure your tokens to have an expiry length. in theory you would convert this 'expiry time from inception' to a date object, and can do one of two things; you can request a new token using the Refresh Token (that comes with the original) once the expiry has been reached, or force the user to re-log in and re issue a new token at this time (i prefer the latter, prevents people from just renewing their tokens forever as long as they remain logged in)
Use the auth token to request user information after login, this can be stored in app state/global variables/wherever. You then want to use the auth token in the Authorization Header for each API call, along with whatever data you are sending. this ensures that even once someone is INSIDE the application, they need to have a valid token to actually do anything involving data (imagine someone back-dooring into your app and skipping the authorization, or using something like postman to just hammer your API with garbage). it would work something like this: GET userData { Header: auth token } -> GET userProfile (by sending your user ID returned from GET userData) PLUS {Header: auth token }
I can give more in depth examples if you wish, and i apologize if i misunderstood any of the question and gave redundant/incorrect answers
Edit: Resources about using secure storage for keys
Document for when to use in-memory storage Vs persistent storage. The TL;DR is use in-memory if the key is expected to expire before a standard session duration, and persistent for storing a key between sessions
https://hackernoon.com/mobile-api-security-techniques-682a5da4fe10
link to Keychain Services doc
https://developer.apple.com/documentation/security/keychain_services#//apple_ref/doc/uid/TP30000897-CH203-TP1
link to SharedPreferences doc
https://developer.android.com/reference/android/content/SharedPreferences.html
AsyncStorage is a simple, unencrypted, asynchronous, persistent,
key-value storage system that is global to the app. [1]
You could store it in your AsyncStorage, but thats not necessarily a secure location itself (e.g. not encrypted, accessible on rooted devices...). Typically clients will issue access tokens that last anywhere from several hours to a couple days and these will provide their owner access to your API-resources. If there is sensitive data behind your login screen, you're probably better off simply re-doing the auth-flow and invalidate older access tokens on login.
I'd like to persist a user's account credentials (i.e. username and password) in my React Native app. Should I use AsyncStorage?
In other words, I want to know if and how AsyncStorage protects its contents. The docs are silent on that.
(I'm using RN v0.28)
Is AsyncStorage secure?
No AsyncStorage is not secure, the docs says:
AsyncStorage is a simple, unencrypted, asynchronous, persistent,
key-value storage system that is global to the app. It should be used
instead of LocalStorage.
To store secure information on the native side, I really recommand you to use react-native-keychain with react-native
For iOS it use Keychain Sharing Capabilities
For Android it use:
API level 16-22 use Facebook Conceal
API level 23+ use Android Keystore
This is a simple example:
// Generic Password, service argument optional
Keychain
.setGenericPassword(username, password)
.then(function() {
console.log('Credentials saved successfully!');
});
// service argument optional
Keychain
.getGenericPassword()
.then(function(credentials) {
console.log('Credentials successfully loaded for user ' + credentials.username);
}).catch(function(error) {
console.log('Keychain couldn\'t be accessed! Maybe no value set?', error);
});
If you are using Expo sdk, you can use SecureStore for sensitive information.
NO (at least on iOS, RN v0.28)
AsyncStorage saves key-value pairs as a plaintext JSON file in the Documents directory.
If you run it in the iOS Simulator, you can find its contents on ~/Library/Developer/CoreSimulator/Devices
Should have been obvious from the source code for RCTAsyncLocalStorage
You should NEVER save the username and password in plain text in client applications. Please note, never save sensitive data in plain text. You should use a token to authenticate the user.
Regarding the security of the AsyncStorage read this answer. TL;DR the data is safe unless the attacker have access to the device or the device is rooted(android)/jailbroken(iOS). The data is not encrypted. So, with root or physical access to the device (and the device is not protected) it is possible to access to that data.