Definitely interesting... not sure I like the store/state management piece, but it's definitely interesting.
One thing that would be nice to see would be browser support. I'm assuming the store is using proxies in order to raise state change events.
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.
Though a bit OT for this site, it's a really nice start to what appears to be a series of articles. Well written, though a bit more short than I'd like for this topic. Looking forward to the followup.
Nice tips for dealing with styled-components. I've been digging react-jss more myself, but it's another interesting approach. I could also see styled-components working better if you're more content heavy then it's probably a better approach vs. more of an application.
Really interesting, but not sure if storybook really works to demonstrate these kinds of components. Would love to see a practical demonstration video.
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.