Long time software architect, CTO Authress, creating application security plug-ins for any software application with Authress. Talk to me about security in microservices or service authorization.
I think the info here is a good start for engineers looking for some introductory knowledge. It would still be good to point out that cookies are actually separate from the JWT access token exchange. Cookies are neither stored in JWT, nor must JWTs be stored in cookies. It would be good to make sure these are separated topics.
Often JWTs are returned with user claims (not cookies) that further identify the user. While it isn't exactly adhering to the OAuth2.0 specs, you can return the JWTs in cookies back to the user. Although more frequently JWTs are returned to the user via url query or hash parameters.
While bcrypt works, I caution about the straw-man laid out here. There's way more that needs to be done that just implementing one function to handle passwords, this actually why most apps on the internet that don't use social logins are so insecure. If you industry regulation (spoiler none of them do) require username and password to login, make sure to do in-depth analysis of all the attack vectors and choosing an appropriate hashing and access token generation strategy. (For instance the one in the article seems to suggest symmetric keys, please use at least RS256 asymmetric keys).
Also I totally agree with the lack of full authorization support in the solution. The optimal strategy for that is a separated handling of roles and permissions. While it is all too common to stuff roles in the JWTs, this is actually a common antipattern. JWTs are meant for identity information, roles are access control. These two resources change at different frequencies and have different cache control requirements as well as security measures implemented.
Additionally granular access is not possible due to header size/cookie size limits when it comes to handling user permissions.
(One side note about using Joi, if you are providing a REST api for your users you want to focus on validating the schema of the payloads using the openapi specification as your primary validation source. While the schema source location is irrelevant, in the past Joi has not done a good job of providing interoperability between the openapi standard and the custom Joi api.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the info here is a good start for engineers looking for some introductory knowledge. It would still be good to point out that
cookiesare actually separate from the JWT access token exchange. Cookies are neither stored in JWT, nor must JWTs be stored in cookies. It would be good to make sure these are separated topics.Often JWTs are returned with user claims (not cookies) that further identify the user. While it isn't exactly adhering to the OAuth2.0 specs, you can return the JWTs in cookies back to the user. Although more frequently JWTs are returned to the user via url query or hash parameters.
While bcrypt works, I caution about the straw-man laid out here. There's way more that needs to be done that just implementing one function to handle passwords, this actually why most apps on the internet that don't use social logins are so insecure. If you industry regulation (spoiler none of them do) require username and password to login, make sure to do in-depth analysis of all the attack vectors and choosing an appropriate hashing and access token generation strategy. (For instance the one in the article seems to suggest symmetric keys, please use at least RS256 asymmetric keys).
Also I totally agree with the lack of full authorization support in the solution. The optimal strategy for that is a separated handling of roles and permissions. While it is all too common to stuff roles in the JWTs, this is actually a common antipattern. JWTs are meant for identity information, roles are access control. These two resources change at different frequencies and have different cache control requirements as well as security measures implemented.
Additionally granular access is not possible due to header size/cookie size limits when it comes to handling user permissions.
(One side note about using Joi, if you are providing a REST api for your users you want to focus on validating the schema of the payloads using the openapi specification as your primary validation source. While the schema source location is irrelevant, in the past Joi has not done a good job of providing interoperability between the openapi standard and the custom Joi api.)