The first challenge for offline applications is data/information architecture to work out how much and what type of data should be stored locally. The local SQLite database can generally grow in size as required but it is still required to keep offline data storage to sensible sizes, if only because huge relational databases are going to take longer to search without careful indexing. Obviously sensitive information should be encrypted but some data should never be stored locally in the first place. The levels of encryption vary per security team requirement but remember the stronger the encryption then the slower it will take to store the data. I am told that decryption speed does not necessarily depend on encryption speed, unless of course you don't have the keys and are just trying to hack into the system. If the encryption desired is taking too long to store the data then maybe hand the encryption over to a separate low priority thread because as long as the encryption either passes or fails as a complete transaction then the storage does not need to be immediate. Good security should not be compromised by solution architecture and you could even use native level code (C/C++) in order to handle the encryption code faster.
The second challenge is how you do authentication offline. The simple answer is you cannot easily. What most people do is after the initial log in, they just store the credentials locally for ever more. This is not very secure because there is no way of revoking the credentials quickly if the phone gets stolen, or controlling the time duration that offline access is allowed for. The main problem is there is no control of the validity of offline access at all, it is all or nothing. Luckily there is a solution that I am starting to pull together due to the growing demand for offline applications. The typical use of an offline application is that when a user loses network coverage then they store a load of encrypted data locally and when they return to an area of network coverage they automatically (or manually) sync the data with an online server. Often there is some data that is always stored locally and that needs to be secured for offline only access.
The use case is as follows: Why should you be online to access a secure offline cache of data?
It is something I get asked for all the time and most security departments just respond that you always need to be online. However if we look at the growing popularity of Single Page Applications (through frameworks such as Angular) then it is possible to write applications that rarely talk with the backend services apart from small deltas of API driven information. Security solutions have to address the fact that applications are not talking to the servers as frequently as in the past - in this brave new API driven world. This has led to an increase in security token solutions such as: JSON Web Tokens (JWT); OAuth 2; and security token service providers like Ping ID.
If we take Ping ID as a case study then we can discuss the art of the possible. Ping ID offers the ability to obtain an OAuth security token and manage its validity. Once you have the security token then you can use it to access other backend systems that support OAuth by passing it into them. The security token lifetime is built to the OAuth standard and the Ping ID tokens are valid for a number of hours. Functionality is typically built in to mobile applications to attempt a token refresh any time an access token validation fails. This is performed through refresh tokens which are valid for a number of days and that can be used to retrieve a new access token without requiring the user to re-authenticate.
The application needs to network with PingFederate to make an access token refresh request. This passes in the refresh token and Ping does a check against its grant database and will respond with both a new access token and a new refresh token. A new refresh token is issued on every refresh to prevent them being replayed but the overall lifetime of the session is not increased. Users would be required to re-authenticate at a minimum number of days depending on the time limit set in the refresh token. If the application wants a shorter refresh token lifetime (such as a single day) then this is configurable. There are other useful options like being able to set early idle-time expiration for refresh tokens or terminating the access grants altogether in the PingFederate database if the mobile device was lost or there was a security breach.
The question is what happens if we are offline? Well, we need to be online to perform an access token refresh request. There is therefore no way of validating the access token or refresh token locally. What is interesting though is that the access token lifetime is returned to the application every time an access token is issued (or refreshed). This means the application could potentially store the access token lifetime returned and use this as a check for allowing access into the mobile application. This would be as opposed to caching the log in credentials forever after the very first log in. Storing the access token is actually safer than storing the log in credentials, because there is no danger of them being stolen and leaked. It is certainly easier to revoke a security token than to change log in credentials in a backend system.
The downside in the current scenario would only allow for a short number of hours of offline access which directly followed an online refresh request. What if you could change the token validity time to a longer period of time though? You could request an authentication whilst online just before you went on a long train journey or into a customer office with no network coverage. You would then have a good few hours of offline access to both read and write secure data before syncing with the online server when you have network connectivity again. This offers a really nice model for time controlled offline mobile application access. If the phone was stolen then an Mobile Device Management solution would still require a network connection to wipe the device, so the concern of an offline device not having an ability to revoke an access token is a moot point anyway. In my mind this is certainly an interesting solution for offline authentication and something I welcome feedback on.
Writer, Speaker, Senior Analyst
Digital Transformation, EBA, Center for the Future of Work Cognizant
View my profile on LinkedIn
Learn about mobile strategies at MobileEnterpriseStrategies.com
Follow me on Twitter @krbenedict
Browse the Mobile Solution Directory
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies
Recommended Strategy Book Code Halos
Recommended iPad App Code Halos for iPads
***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.