Chapter 11. Working with Security

User management and conditional access in various forms has become almost ubiquitous in modern apps, and modern users expect the possibility of logging in with an account that they already have or registering and using a new one. Further, they expect that the data that they make available under their accounts will remain secure and in compliance with the applicable privacy legislation.

In this chapter, we will explore how we can add security to our Ionic application, which meets most of these demands. We will start by explaining how routing between views in Ionic works and how we can secure access to individual routes. Finally, we will give some pointers to further reading, including advanced authentication concepts such as OAuth.

An overview of client-side security

We will start off by briefly discussing some core concepts that are involved in securing client applications, such as the apps that we are developing in this book.

Client-side security is a convenience

The first thing that you need to know about client-side security is that there really is no such thing as client-side security. The app that you deliver to your users, whether native or hybrid, is exposed to the possibility of tampering, reverse engineering, cracking, and a number of other things that fundamentally compromise its integrity. Thus, you can never really trust client applications with the important part of security in your app, which is ultimately required to safeguard your users' private information and make sure that unauthorized users cannot access data that they should not be allowed to access. In particular, this data is private and cannot be accessed by other users. In fact, many of the most severe blows in terms of security failures of larger companies has been due to user data being compromised and leaked en-masse to unauthorized parties.

However, you can provide security that is good enough for the app's intended use. For example, even if it will not guarantee complete security, you can still attempt to deter less severe privacy invaders from trying to glean personal data from an app by using more advanced security measures such as fingerprint scanners on some devices, or by using encryption on local data while forcing users to pick very strong encryption keys.

The fact that client-side security is not a final measure in safeguarding your users' data should of course not deter you from using it. In fact, client-side security brings a lot of benefits in terms of how we structure our apps. Importantly, it allows us to to create rich user experiences, where the sections of the app accessible to the user can be limited based on the users' authentication status.

The basic components of client-side security

While details may vary across different systems and implementations, there are some fundamental concepts of client-side security that are in use almost everywhere. The following are some of the concepts:

  • Authentication tokens: These are data that uniquely identify an authenticated user in a system. They are granted by the system itself—or an associated, trusted system—in response to the user providing legitimate authentication information to the system. For example, this information can be a username-password pair, a fingerprint/iris scan, or some other trusted means of authentication.
  • Secure local storage: In order to improve user experience, we most certainly do not want to force our users to authenticate themselves every single time they use the app. Just imagine a situation where you had to log in again to every single account on your device every time you restarted it! In order to work around this, we use some kind of secure storage, where the access tokens stored under the previous step are preserved. The app itself then simply extracts the token from this storage and uses it in order to perform authenticated communication with the server. The term secure local storage implies some necessary security measures as regards how access tokens are stored and retrieved. This is necessary since a compromised access token will allow an unauthorized party to be masked as the legitimate user. On most mobile devices, there are native features for storage where security is handled by the resident operating system. In other cases, developers can opt to use other solutions, such as an encrypted file storage that require some external mechanism to unlock the system.
  • Secure communication: Access tokens can be compromised in storage. Furthermore, they are also open to theft while in transit. For example, various types of man-in-the-middle attack, where an attacker is masked as a legitimate endpoint for a network connection, can be used in order to intercept an access token during a transfer in order to steal it and consequently, the user's access privileges. In most cases, secure communication is nothing that you as a developer have to worry about implementing manually. Encrypted connections via HTTPS are increasingly becoming the standard way of communication across the Internet, and they provide very robust security for data over network endpoints. Meanwhile, support for it is present in the network stacks of virtually all major operating systems, both for stationary and mobile devices.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.54.255