With browser-based apps there is always a risk of things like Cross-Site Scripting (XSS) attacks due to the increased attack surface and number of moving parts in websites. Additionally, browsers currently don’t have a secure storage mechanism available to store things like the access token or refresh token. As such, browsers are always considered a higher risk in an OAuth deployment compared to other platforms, and the authorization server will usually have special policies around token lifetimes to mitigate that risk.
Additionally, the additions of browser APIs such as
ServiceWorkers means that now browser-based apps have the potential to run code when the user isn’t actively using the browser, such as in response to a Background Sync event. This means there is now more potential use for refresh tokens in browser apps.
Refresh tokens must also either have a set maximum lifetime, or expire if they are not used within some amount of time. This is again another way to help mitigate the risks of a stolen refresh token.
The browser-based app will need to temporarily store some pieces of information during the authorization flow, and then permanently store the resulting access token and refresh token. This provides some challenges in the browser environment since there are currently no general-purpose secure storage mechanism in browsers.
Generally, the browser’s
LocalStorage API is the best place to store this data as it provides the easiest API to store and retrieve data and is about as secure as you can get in a browser. The downside is that any scripts on the page, even from different domains such as your analytics or ad network, will be able to access the
LocalStorage of your application. This means anything you store in
LocalStorage is potentially visible to third-party scripts on your page.
Because of the risks of data leakage from third-party scripts, it is extremely important to have a good Content-Security Policy configured for your app so that you can be more confident that arbitrary scripts aren’t able to run in the application. A good document on configuring a Content Security Policy is available from OWASP at https://owasp.org/www-project-cheat-sheets/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
Choosing an Alternative Architecture
This pattern is described in more detail in “OAuth 2.0 for Browser-Based Apps“.