Learn how to add authentication and authorization to gRPC for microservices in .NET Core.
Brought to you by @andrea.chiarelli
Please let us know if you have any questions on this front!
Let me know your experience on securing gRPC in .NET Core!
In the last section, the CreateAuthorizedChannel method creates a GrpcChannel which uses an access token to set the Authorization header during requests. In this sample, I noticed that there was no logic for checking if the token is expired and then refreshing it if it is. I was wondering if there are any articles that show a best practice for doing this with CallCredentials and GrpcChannel class.
For example, is there a way for the GrpcChannel to validate the token before each request and then generate a new one if necessary?
I find this to be important because Auth0 limits the number of machine to machine tokens that can be generated each month. It would not be ideal to create a new one each time the program runs.
Hi @w1ll,
Thanks for reading my article and joining the Auth0 Community.
As mentioned in the article, for a production-ready application you need to implement a caching mechanism for the access token.
As far as I know, this is not related to CallCredentials and GrpcChannel classes. You should implement it in the GetAccessToken() method.
I’m afraid that currently, we have no article showing how to implement this caching mechanism. However, I hope that the approach outlined here is useful for your needs.
1 Like
Dear andrea,
Great articles both Implementing Microservices with gRPC and .NET Core 3.1
and this one. You mentionned that both server and client “are meant to run on the server side, so both applications are not publicly accessible” (M2M scenario), therefore you are using Client Credentials Flow.
What about if the client and server are running on 2 separate computers?
Hi @karimgsaikali2, thank you for appreciating my articles and joining to the Auth0 Community!
Regarding your request, the requirement for the M2M scenario is that the client and the server run on the server side. This doesn’t mean that they need to run on the same server. They can run on different machines, provided that they are servers.
The basic principle is that both client and server are not public clients, that is, applications that cannot grant the confidentiality of their secrets. If you are implementing microservices, there are chances that you are creating applications that run on the server (not necessarily on the same server). So, they are good candidates for the M2M scenario.
I hope that this helps to clarify your concern.
Hello,
Is it a good idea to use interceptors instead of authorizationchanel to attach the auth token?
Hey @7amou3,
Welcome to Auth0 Community, and thanks for reading this blog post!
I’ve no specific experience with Interceptors; however, as far as I know, they are the suggested solution for ASP.NET applications calling a gRPC server.
The client described in the article is a console application and doesn’t rely on ASP.NET.
I hope this helps with deciding which approach to use.
Hey @andrea.chiarelli
Thanks for your reply,
I went with the secure chanel route, because for the interceptor case, I needed to overide every call type made by the client (wich i found tedious).
in my case i don’t create the channel for every request, ASP.NET provide a factory that can resolve client from DI container
Dear Andrea and Auth0 Team, many years are gone without any updates was been applied on securing gRPC-based Microservices in .NET/ Blazor technology. could you kindly take up this topic and update it to the latest releases ? a devoted reader of yours precious Articles !! 
Hey @enrico.triveri,
Thank you for appreciating my articles. I hope they have helped you.
Regarding the article update, there are no plans to update it in the near future. However, we will consider your request and will notify you here when it will be updated.
Thank you for reporting. Stay tuned!