Securing Tokens In A Progressive Web App
Security is at the top of the agenda for every technological development, especially so in the open world of the World Wide Web and Internet generally. The core underlying challenge is that the web and Internet were not designed with a modern level of security in mind. This makes creating web experiences that are both highly usable and highly secure difficult.
OAuth And Distributed Identity Services
In recent years technologies such as federated identity, OAuth ans Single Sign On have all become very popular on the web. Instead of having one hundred different user names and passwords for one hundred different web portals, users can have one username and password provided by a trusted partner (e.g. Azure Active Directory) and use that to log in to all their web portals without having to disclose the password to those systems. This is accomplished using a system of secure “tokens” that authorise users to access different systems.
For illustrations, let’s say we are building an Angular 7 Progressive Web App (PWA) that is authorised using OAuth against an Azure Active Directory. The Angular App accesses a web API that is hosted on an App Service in Microsoft Azure. APIs frequently request an OAuth token to be provided by the client (the PWA here) with every request.
Do Not Use Web Storage
Similarly, client-accessible cookies are similarly vulnerable to very simple attacks.
Use Secure HTTP Only Cookies
CSRF / XSRF Tokens
Obviously this gives rise to a cross-site scripting vulnerability with the CSRF token which should be defended against using the normal mitigations. A combination of good cross-site scripting hygiene, a secure HTTP only cookie for authentication and a CSRF token is a good combination for building a secure eco-system for your PWA and web API.
Indirect All API Calls
Another excellent solution to the above quandary is to simplify web API access by constructing your PWA in such a way that ALL web API calls are ONLY to the domain that hosts both the PWA and the web API. This means that you will be able to take advantage of the “same site” capability of modern browsers and cookies, although this cannot be 100% relied upon due to older browsers still being in use. It also means that you can perform some server side programming to include the CSRF in the HTML served up for the client-side app rather than sending it around in cookies.
In this scenario, all access to third party APIs will be managed by the server-side component of the PWA. This allows much more secure methods for web API credential storage to take place on the server side rather than insecurely on the client side. This is very useful when accessing a web API that requires the passing of an OAuth token in a header, for example.