Update where to store tokens information

Author: erjohnson

articles/security/store-tokens.md

@@ -10,42 +10,24 @@ contentType:
 useCase:
   - development
 ---
-# Where to Store Tokens
-
- This document explains how to securely store tokens used in token-based authentication. The following assumes a basic knowledge of JSON Web Tokens (JWTs). To learn more about JWTs see:
-
- * [Auth0 Tokens](/tokens)
- * [JSON Web Tokens (JWT) in Auth0](/jwt)
-
-## Where to Store Your JWTs
-
-::: warning
-You __must__ [verify a JWT's signature](/tokens/id-token#verify-the-signature) before storing and using it.
-:::
 
-With token-based authentication, you are given the choice of where to store the JWT. We strongly recommend that you store your tokens in local storage/session storage or a cookie.
-
-### Web Storage (local storage/session storage)
-
-Commonly, the JWT is placed in the browsers local storage and this works well for most use cases.
+# Where to Store Tokens
 
-When logging in a user with a username and password, the response body contains the Access Token JWT. Then you need to handle this response in the client side code. This token can then be stored in localStorage or sessionStorage.
+This document explains how to securely store [tokens](/tokens) used in token-based authentication.
 
-[Click here for an example using sessionStorage](https://github.com/auth0-blog/angular-token-auth/blob/master/auth.client.js#L31)
+## Do not store tokens in the browser
 
-Both `localStorage` and `sessionStorage` both extend `Storage`. The only difference between them is the persistance of the data:
+You should not store tokens in the browser's local storage or session storage. Data stored in the browser is vulnerable to [cross-site scripting](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)) and malicious parties can potentially steal or alter that data.
 
-`localStorage` - data persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.
+## Store tokens when a backend is present
 
-`sessionStorage` - Changes made are saved and available for the current page, as well as future visits to the site on the same window. Once the window is closed, the storage is deleted.
+If your application has a backend server at all, then you should use the [Authorization Code flow](/application-auth/current/server-side-web) for authentication. Native applications should use the [Authorization Code flow with Proof Key for Code Exchange](/application-auth/current/mobile-desktop).
 
-#### Web Storage Disadvantages
+## Store tokens without a backend
 
-* Unlike cookies, local storage is sandboxed to a specific domain and its data cannot be accessed by any other domain including sub-domains.
-* Web Storage is accessible through JavaScript on the same domain so any JavaScript running on your site will have access to web storage, and because of this can be vulnerable to cross-site scripting (XSS) attacks.
-* The developer must ensure that the JWT is always sent over HTTPS and never HTTP.
+If you have a single page application (SPA) with no corresponding backend server, your SPA should request new tokens on page load and store them in memory without any persistence. To make API calls, your SPA would then use the in-memory copy of the token.
 
-### Using Cookies
+## Using Cookies
 
 You can also use cookies to store the JWT. The exact way to set a cookie depends on the client side language you are using.
 
@@ -72,10 +54,6 @@ This video will show you how to handle session data when building a web app. It
 * Cookies can be vulnerable to cross-site request forgery (CSRF or XSRF) attacks. This type of attack occurs when a malicious web site causes a user’s web browser to perform an unwanted action on a trusted site where the user is currently authenticated. This is an exploit of how the browser handles cookies. Using a web app framework’s CSRF protection makes cookies a secure option for storing a JWT. CSRF can also be partially prevented by checking the HTTP `Referer` and `Origin` header.
 *  Can be difficult to implement if the application requires cross-domain access. Cookies have additional properties (Domain/Path) that can be modified to allow you to specify where the cookie is allowed to be sent.
 
-## How to implement
-
-Many of our Quickstarts demonstrate how to store tokens, and the exact implementation will be different based on the technology being used. Please refer to the Quickstarts at the top of our [Documentation Home Page](/), select the appropriate Quickstart based on your application type, and follow the code samples provided.
-
 ## Keep reading
 
 ::: next-steps