I'm quite new to the .NET microservices architecture and right now I'm implementing a .Net app for learning management and it consists of several microservices and an API gateway - Ocelot.
So the authentication is handled in the gateway (bearer token)
And for the authorization part, I have some concerns: I have a dedicated microservice that holds the user's roles permissions, and scopes and I was thinking that in the gateway have a middleware on each request to fetch the user permissions and scopes and add them in the request header. Then on the microservice layer on each controller endpoint, I use a dedicated TypeFilterAttribute in which I pass a list of strings and optionally an operator that could be or/and. In the custom filter in OnAuthorization method, I extract the user's permissions and apply the validation logic taking into account the required permissions and the operator that is passed through the custom attribute. For the gateway, I could also implement caching for the user permissions.
Could be this a reliable solution? Maybe it's not a good idea to pass the permissions and scopes in the request header because it could exceed the size limit and I assume that if only the gateway is exposed public there is no risk. What other alternatives do you see or use?
For the sake of simplicity I will assume here that the number of privilege types is lesser or equal with 64, in which case you can represent your privileges as bits of a number.
If your number is represented on 64 bits, then that's 8 bytes and takes up only a few digits will be needed. You can compress this further by compressing it into base64 to make it even shorter.
Now, if you have more than 64 privilege types, then you can break them down into several numbers and compress them together via base64.
However, there is a security issue here. If I as a user can send the privileges as a bearer token and assuming that I figure out how the privileges are being represented, then I could log in with a lesser-privileged user and claim inside the request that the referrer is your trusted app and that I have superadmin privileges.
So your approach is not very safe and it makes more sense to either encode the entire data that's passed into a very secure temporary-live token (JWT), which will be valid exactly at its first use, or you avoid sending the privileges and, instead, your client app sends a request back to the server that is your source of truth (IDP) for the privileges, which will guarantee that the privileges are received from the correct location and you will not even have to worry about the size of the response.