Add a section about storing tokens in JS

[aaronpk]

• storing tokens available to JS opens up new XSS attack vectors
• LocalStorage and IndexedDB are protected by the same origin policy so at least third party scripts can't access data there

[eZanmoto]

I think it would be good to have such a section to promote such best practices in a concrete way, but I see a problem in having it be too reliant on existing technologies since it can go out of date so quickly. I don't keep up to date with browser developments too much, but it seems like the recommendation has gone from keeping tokens solely in memory (possible with silent renew), to keeping tokens in the storage mechanisms you mentioned, to possibly keeping them in WebWorkers (pending investigation). We may even see this change again if browsers support a secure local storage system, or once the WebID proposal makes it, etc. Because of these, it might make more sense to have the section detail the desired properties that tokens would be stored with, and like you mentioned, the different attack vectors that we know are associated with each. For example:

• Access tokens should ideally be:
  • Stored in memory only, and not saved to persistent storage. This prevents malicious third-party scripts included in the first party application (e.g. NPM dependencies) from retrieving the token from the persistent storage.
  • Stored in WebWorkers, if in-memory storage isn't possible. (Reasons)
  • Stored in LocalStorage or IndexedDB, if WebWorkers storage isn't possible. (Reasons)
  • Stored in a closure variable, as opposed to an object property. This prevents malicious third-party scripts included in the first party application (e.g. NPM dependencies) from accessing the variable via reflection. (NOTE Does marking a property as private achieve this behaviour?)
  • Managed by a "token manager" class, which only provides access to the access token (in the case where the token manager also handles refresh tokens). The "token manager" class should only have one, non-global instance, which should only be accessible by a service class, which uses the access tokens directly in service calls. Having a token manager class allows for separation of concerns in the codebase, and reducing the number of objects that can use this manager be limited to a single service instance reduces the possibility of an access token being retrieved by an object that doesn't require it.
• Refresh tokens should follow the same storage precautions as access tokens, but should additionally be:
  • Not returned to the frontend. (Reasons)
  • Managed by WebWorkers, if handled on the frontend. (Reasons)

Note that JS isn't my speciality so take these suggestions with a pinch of salt.

[aaronpk]

Alright, this is a lot, but I finally put together the start to this section. I'm definitely open to suggestions and corrections. Here's the link to the current draft:

https://drafts.oauth.net/oauth-browser-based-apps/draft-ietf-oauth-browser-based-apps.html#name-token-storage-in-the-browse

It's kind of a wall of text right now, so probably could use some help breaking it up into different sub-headers.

[aaronpk]

This now has section headers and is a lot more readable. I also added a new section about sender-constrained tokens as well as a reference to DPoP.