There's absolutely no issue with JWTs holding user attributes, especially in an architecture where it is refreshed often. What it shouldn't be, is an authorization solution which you reference in your code to make authorization decisions (creating a static policy), nor should it be an ACL storage (creating a static data storage).
Agreed. Have you checked out the Phantom Token Pattern? It's not specific to holding fine-grained authorization data in the JWT but it does target the "don't use JWTs everywhere" case and prevents JWTs from potentially leaking PII in public clients. https://curity.io/resources/learn/phantom-token-pattern/
The JWT can hold identity data used by an authorization engine (ABAC). It could also hold context attributes that are used to determine authorization.
There's absolutely no issue with JWTs holding user attributes, especially in an architecture where it is refreshed often. What it shouldn't be, is an authorization solution which you reference in your code to make authorization decisions (creating a static policy), nor should it be an ACL storage (creating a static data storage).
Agreed. Have you checked out the Phantom Token Pattern? It's not specific to holding fine-grained authorization data in the JWT but it does target the "don't use JWTs everywhere" case and prevents JWTs from potentially leaking PII in public clients. https://curity.io/resources/learn/phantom-token-pattern/