Echo JS 0.11.0

While mostly useful, I do have a few criticisms...

1) there's an exp (expires) attribute already, you can use short lived (5 minutes) and/or refresh tokens for automated systems, and slightly longer for use with an SPA client.

2) regarding revocation, have a key/value store that keeps a revocation list, and have those items auto-expire when the token expires to keep that collection lean.  Redis is a great use case for this.  Do *NOT* fiddle with a server-side duplication of tokens generated as the article indicates.

3) cache decoded tokens and secondary lookups.  For example, in a system I am working on a token will indicate an affiliation and roles associated for that use.  This gets flushed out with some additional data from the DB that's used through the server-side.  While this can be fetched at any time, a good caching strategy is helpful here.

4) client-storage, generally the token is sent on the querystring/url, best to store in an incapsulated variable (as suggested), but also to immediately do a client-side URL replace.  

    export const clearAuthorizationQuery = _ => {
      const { search, pathname } = window.location;
      const query = qs.parse(search.substr(1));
      delete query.authorization;
      let q = qs.stringify(query);
      if (q) q = `?${q}`;
      window.history.replaceState({}, 'hide-authorization', `${pathname}${q}`);
    };

continued, if you aren't running potentially untrusted code, you can use localStorage to stow your token, combined with short lived keys and a refresh token, you limit your exposure risk.  There are other considerations if your front end is a static delivery site... since you cannot inject the token for authentication when doing so.  You *could* do this at your API layer, and support either a cookie, or the Authentication header.

----

There are other considerations, and this topic (authorization/authentication/security) could cover an entire book.