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. In terms of progressive web app development, this makes creating web experiences that are both highly usable and highly secure difficult. Appropriate progressive web app security can be achieved however, here are a few of our expert tips and methods to help you.

How to Secure Tokens In A Progressive Web App

Use OAuth And Distributed Identity Services

In recent years, technologies such as federated identity and OAuth ans Single Sign On have 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 illustration, 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. Learn more about integrating Auth0 with Azure Active Directory.


Do Not Use Web Storage

A simple plan would be to write some Typescript/Javascript for your PWA that logs the user in, gets the OAuth token from Azure Active Directory and stores it in the convenient Web Local Storage or Session Storage of the browser. The PWA can then load the token from web storage when needed and provide it to the API. This solution is simple and frequently implemented, but it is also fundamentally insecure. A discussion of why is beyond this article’s scope, but suffice it to say that web storage is vulnerable to simple cross-site scripting attacks. Similarly, client-accessible cookies are vulnerable to very simple attacks.

Use Secure HTTP Only Cookies

To avoid the problems outlined above needs a little bit more work. The preferred approach at McKenna Consultants is to log in to the auth provider (e.g. Azure AD) via the PWA and immediately use the token retrieved to call a “login” method on the API (passing it the token) without storing the token retrieved from Azure AD anywhere on the client-side. The API would then validate the token passed in (for example, using the ADAL library) and issue its own authorisation cookie (for example, using simple ASP.Net forms authentication). The cookies issued MUST have the “secure” and “HTTP Only” flags set. Therefore, it means that the client-side Javascript/Typescript cannot read the cookie. The browser is responsible for dispatching the cookie with every HTTPS request to the API, solving the cross-site scripting problem and securing your progressive web App.

Take Care With CSRF / XSRF Tokens

Our next problem is that the PWA domain may not match the API domain (if they are hosted in the same server-side web service then this is an easy problem to solve), so we have a cross-site request forgery (XSRF or CSRF)  problem. The main defence against this is the “synchronised token” approach. This defence is implemented, for example, in the Asp.Net RequestValidationToken approach. Microsoft recommends sending and receiving the CSRF token between the PWA and web API using a secure cookie (not HTTP only in this case). Essentially this gives us an overall more secure solution by using both a secure HTTP only cookie for the auth token and a secure Javascript-readable cookie for the CSRF token.

Obviously, this gives rise to a cross-site scripting vulnerability with the CSRF token, which should be defended against using 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 ecosystem for your PWA and web API.


Consider Indirect All API Calls

An excellent solution to the above quandary is to simplify web API access by constructing your PWA so that ALL web API calls are ONLY to the domain that hosts both the PWA and the web API. This means that you can take advantage of modern browsers and cookies’ “same site” capability, although this cannot be totally 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 PWA server-side component. This allows more secure web API credential storage methods to occur 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.

Benefits of Securing Tokens In A Progressive Web App

Securing progressive web Apps is made more simple as the secure contexts (HTTPS), service worker(s) and manifest file features include added security measures to stop malicious users infiltrating your App. The security benefits of PWAs are explained below:

  1. Secure contexts (HTTPS)

A PWA must be served over a secure network to be entrusted by users, particularly where a monetary exchange is involved. PWAs are SSL encrypted by browsers, making them more secure than connections in traditional native Apps.

  1. Service workers

Service workers are a script run separately from your main browser that intercepts network requests, deals with caching and enables browser support. Essentially, they are a proxy between the front and backend of a web App. Service workers are only registered on HTTPS encrypted browsers so that they cannot be tampered with and have additional security features to limit the impact of malicious server workers, explained below:

  • Service workers are Javascript workers and so don’t have access to the DOM or the cookies directly. Rather, they communicate with other pages with the postMessage interface.
  • Service workers only have access to the Cache Storage and indexedDB for caching purposes but not the Local Web Storage or Session Storage.
  • Service workers can’t read or set forbidden headers.
  1. Manifest file

The manifest file in a PWA sits in the HTML, and it is responsible for the display and appearance of your App, including name, background colour, icon, etc. When a manifest file is present, a malicious attacker cannot override the manifest and target the App. Therefore the name, description and icon of your PWA remain secure.

Additional Benefits of PWAs:

  • Automatic updates

PWAs benefit from browser support and automatic maintenance and utilise these technologies to deliver an optimal web experience for users. Automatic updates and maintenance mean that a high level of security is maintained.

  • Improved performance

PWAs take advantage of new technologies to make a more powerful web App without impinging on device storage or mobile battery life. The caching done by service workers enables PWAs to install and load faster, even when operating offline.

  • Improved user experience

PWAs are designed to provide a good, secure user experience. Once installed, users can view the PWA icon on their home screen and access PWAs from their device as they would use a native App. Service workers can re-engage users using push notifications when they’re not actively using their browser. Plus, PWAs are network independent, utilising cache storage, meaning users can browse content or sites even when offline.

For a more detailed explanation of PWAs and their benefits, have a read of our blog. Or, if you wish to discuss securing progressive web Apps in more detail, please contact us to speak to one of our friendly specialists.

Nick McKenna
Since 2004, Nick McKenna, BSc, MBCS Biography has been the CEO of McKenna Consultants. McKenna Consultants is a bespoke software development based in North Yorkshire, specialising in Cloud development, mobile App development, progressive web App development, systems integration and the Internet of Things development. Nick also holds a First Class Degree in Computer Science (BSc) and wrote his first computer program at the age of nine, on a BBC Micro Model B computer. For the last 21 years, Nick has been a professional computer programmer and software architecture. Nick’s technical expertise includes; Net Core, C#, Microsoft Azure, Asp.Net, RESTful web services, eProcurement, Swift, iOS mobile development, Java, Android mobile development, C++, Internet Of Things and more. In addition, Nick is experienced in Agile coaching, training and consultancy, applying modern Agile management techniques to marketing and running McKenna Consultants, as well as the development of software for clients. Nick is a Certified Enterprise Coach (Scrum Alliance), SAFe Program Consultant (SAI), Certified LeSS Practitioner (LeSS) and Certified Scrum@Scale Practitioner. Outside the office, Nick is a professional scuba diver and he holds the rank of Black Belt 5th Dan in Karate.