Big security problems and opens the way for an XSS attack that in most cases can’t be stopped. Also if you don’t have a blacklist for rejected tokens or the blacklist gets leaked your application will get crashed.
All your data will be owned by the hacker(deleting stealing your data or manipulating it).
Summary: Always use session cookies unless your are not on a browser(mobile), but even then still use cookie based session, because they are much more secure.
Some information can be found here from a security expert at okta @rdegges
But there is no built in roles/permissions. I prefer to hard code roles/permissions, and would only want to keep them in the db if I were to permit users to micromanage permissions.
@alchemist_ubi has been working on an IAM library. I’m not sure how far he has come, but it might be what you are looking for.
Because it’s stateless which makes it super easy to spin up numerous Phoenix/Plug instances dynamically without having to deal with distribution of session cache. Makes sense for e.g. API’s with very high traffic load, as soon as the instance is online it can deal with the JWT without even having to be connected to any cluster.
A cool thing is that you can even use JWT in stateful sessions, as it’s just a token. You can check the session cache at critical endpoints, and still have extremely fast responses for other places without the need to check the cache. It could be argued that it goes somewhat against the idea that tokens should be completely random strings without any information, and should only be used as a key to fetch the actual data in a K/V store. But there are probably more knowledgeable people here who can talk about what weaknesses there may be.
It’s probably the best for what it’s designed for, but there is a multitude of ways to handle auth. For sessions I still prefer completely random strings.