I was thinking in that it is OK to put roles/permissions in the JWT payload, however it could become very very large, and we have to account for header limits: stackoverflow.com/questions/686217...
Even if we have low-level permissions Posts.Manage.UpdateOwn, and we can send it in the JWT payload, the data could be very large as more permissions are created, but most importantly, the Posts microservice should be able to check the business rule regarding Posts.Manage.UpdateOwn.
So we have two options here, given a request PUT /users/profile
1) In the controller, you get the User and the Post object and send them to /authorize/Posts.Manage.UpdateOwn with the Post and User object's serialized, and then you check that Post.ownerId === User.id and return true or
2) In the Posts microservice you do the following check: permissions.includes('Posts.Manage.UpdateOwn') && Post.ownerId === User.id
Thanks for the article!
I was thinking in that it is OK to put roles/permissions in the JWT payload, however it could become very very large, and we have to account for header limits: stackoverflow.com/questions/686217...
Even if we have low-level permissions Posts.Manage.UpdateOwn, and we can send it in the JWT payload, the data could be very large as more permissions are created, but most importantly, the Posts microservice should be able to check the business rule regarding Posts.Manage.UpdateOwn.
So we have two options here, given a request PUT /users/profile
1) In the controller, you get the User and the Post object and send them to /authorize/Posts.Manage.UpdateOwn with the Post and User object's serialized, and then you check that Post.ownerId === User.id and return true or
2) In the Posts microservice you do the following check: permissions.includes('Posts.Manage.UpdateOwn') && Post.ownerId === User.id
I think that the second one makes more sense.
@jorgesivil How did you handle header limits?
By setting only the necessary information (like userid) and then having an endpoint to retrieve the full list of permissions