Securing gRPC-based Microservices in .NET Core

Learn how to add authentication and authorization to gRPC for microservices in .NET Core.

Brought to you by @andrea.chiarelli

Read On

1 Like

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.