🙌🏻 🖕🏽 🤰🏼 Authentification dans .NET Core gRpc avec JWT 🌺 🌊 😔

Dans cet article, je parlerai des fonctionnalités de l'authentification API dans les services gRpc utilisant JWT. Je suppose que vous connaissez les en-têtes JWT et HTTP qui les utilisent dans .NET Core WebAPI, donc je ne discuterai pas de ces détails. Lorsque j'ai essayé d'implémenter l'authentification dans gRpc, je suis tombé sur le fait que la plupart des exemples sont écrits à l'aide d'applications console. C'est trop loin de la réalité dans laquelle vivent, à mon avis, les développeurs. Par exemple, je ne souhaite pas créer de chaîne à chaque fois que je souhaite appeler une méthode de service. Je ne veux pas non plus me soucier d'envoyer un jeton et des informations utilisateur à chaque demande. Au lieu de cela, je veux avoir un niveau d'infrastructure qui s'occupera de tout cela pour moi. Si ce sujet vous intéresse, il y en aura plus sous la coupe. Tous les exemples de cet article sont valides pour .NET Core 3.1.

Exemple utilisé

Avant de plonger dans le sujet, il convient de décrire l'exemple utilisé dans l'article. L'ensemble de la solution se compose de deux applications: un site Web et un service gRpc (ci-après API). Les deux sont écrits en .NET Core 3.1. L'utilisateur peut se connecter et voir certaines données s'il y est autorisé. Le site Web ne stocke pas de données utilisateur et s'appuie sur une API dans le processus d'authentification. Pour communiquer avec le service gRpc, le site Web doit avoir un jeton JWT valide, mais ce jeton ne s'applique pas à l'authentification des utilisateurs dans l'application. L'application Web utilise des cookies de son côté. Pour que l'API sache quel utilisateur fait la demande au service, des informations à ce sujet sont envoyées avec le jeton JWT, mais pas dans le jeton lui-même, mais avec un en-tête HTTP supplémentaire. La figure ci-dessous montre un exemple de schéma du système dont je viens de parler:

Ici, je dois noter que lorsque j'ai fait cet exemple, je n'avais pas pour objectif de mettre en œuvre la méthode d'authentification la plus correcte pour l'API. Si vous souhaitez voir certaines des meilleures pratiques, consultez la spécification OpenID Connect . Bien que, parfois, il me semble que la solution la plus correcte peut être redondante par rapport à ce qui peut résoudre le problème et économiser du temps et de l'argent.

Activer l'authentification JWT dans le service gRpc

La configuration du service gRpc n'est pas différente de la configuration habituelle requise par l'API .NET Core. Un avantage supplémentaire est qu'il n'est pas différent pour les protocoles HTTP et HTTPS. En bref, vous devez ajouter des services d'authentification et d'autorisation standard, ainsi que des middlewere dans le fichier Startup.cs . L'endroit où vous ajoutez le middleware est important: vous devez l'ajouter exactement entre le routage et les points ( il manque du code ):

public void Configure(...) {
    app.UseRouting();
    
    app.UseAuthentication();
    app.UseAuthorization();
    
    app.UseEndpoints(...
}

Mais l'endroit où les services sont enregistrés n'est pas si important, ajoutez simplement la méthode ConfigureServices () à la méthode . Mais ici, vous devez configurer la vérification du jeton JWT. Il peut être défini ici, mais je recommande de le retirer dans une classe distincte. Ainsi, le code peut ressembler à ceci:

public void ConfigureServices(...) {
    services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(o => {
            var validator = new JwtTokenValidator(...);
            o.SecurityTokenValidators.Add(validator);
        });
    services.AddAuthorization();
}

La classe JwtTokenValidator est celle où vous définirez la logique de validation. Vous devez créer la classe TokenValidationParameters avec les paramètres corrects et elle fera le reste du travail de validation JWT. En prime, vous pouvez ajouter une couche de sécurité supplémentaire ici. Il peut être nécessaire car JWT est un format bien connu. Si vous avez JWT, vous pouvez aller sur jwt.io et voir quelques informations. Je préfère ajouter un chiffrement supplémentaire au JWT, ce qui rend le déchiffrement plus difficile. Voici à quoi pourrait ressembler un validateur:

public class JwtTokenValidator : ISecurityTokenValidator
{
    public bool CanReadToken(string securityToken) => true;
    
    public ClaimsPrincipal ValidateToken(string securityToken, TokenValidationParameters validationParameters, out SecurityToken validatedToken)
    {
        var handler = new JwtSecurityTokenHandler();
        var tokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = "your string",
            ValidAudience = "your string",
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your secrete code"))
        };
        
        var claimsPrincipal = handler.ValidateToken(token, tokenValidationParameters, out validatedToken);
        return claimsPrincipal;
    }
    
    public bool CanValidateToken { get; } = true;
    public int MaximumTokenSizeInBytes { get; set; } = int.MaxValue;
}

Et c'est tout ce dont l'API a besoin. L'historique de configuration du client est légèrement plus long et légèrement différent selon le protocole HTTP ou HTTPS sélectionné.

Envoi d'en-têtes HTTP avec chaque demande au service gRpc

Vous le connaissez peut-être dans la documentation officielle, que vous ne pouvez en fait utiliser nulle part sauf dans un programme de console stupide. Par exemple, vous pouvez le voir ici .

var channel = GrpcChannel.ForAddress("https://localhost:5001");
var client = new Greeter.GreeterClient(channel);
var response = await client.SayHelloAsync(
    new HelloRequest { Name = "World" });
Console.WriteLine(response.Message);

Pour l'utiliser dans un vrai projet, nous avons encore besoin d'avoir une configuration centralisée et DI, qui ne sont presque pas considérés. Voici ce que tu dois faire. Tout d'abord, nous devons ajouter les packages NuGet nécessaires à notre projet. Le package Grpc.Tools vous aidera à créer des prototypes lors de la construction d'un projet, et Grpc.Net.ClientFactory vous aidera à configurer DI. Lorsque vous travaillez avec gRpc, si vous devez implémenter votre traitement quelque part au milieu de la chaîne de requête-réponse, vous devez utiliser des classes héritées d' Interceptor , qui fait partie de gRpc.Core . Si vous devez accéder à HttpContext.User.Identity au sein de vos services, vous pouvez ajouter l'interface IHttpContextAccessor

dotnet add package Grpc.Net.Client
dotnet add package Google.Protobuf
dotnet add package Grpc.Tools
dotnet add package Grpc.Net.ClientFactory

à votre service (cela nécessite une inscription supplémentaire dans les services). Vous devez ajouter ce qui suit à votre fichier Startup.cs.

services.AddTransient<AuthHeadersInterceptor>();
services.AddHttpContextAccessor();

var httpClientBuilder = services.AddGrpcClient<MygRpcService.MygRpcServiceClient>(o => { o.Address = new Uri("grpc-endpoint-url"); });
httpClientBuilder.AddInterceptor<AuthHeadersInterceptor>();              
httpClientBuilder.ConfigureChannel(o => o.Credentials = ChannelCredentials.Insecure);

La classe AuthHeadersInterceptor est notre propre classe, dérivée de la classe Interceptor . Il utilise IHttpContextAccessor et l'enregistrement .AddHttpContextAccessor () vous permet de le faire.

Fonctions de configuration pour HTTP

Vous pouvez remarquer la configuration suivante:

httpClientBuilder.ConfigureChannel(o => o.Credentials = ChannelCredentials.Insecure);

Il est nécessaire pour travailler via HTTP, mais ce n'est pas suffisant. Vous devez également exclure cette ligne de la méthode Configure ().

app.UseHttpsRedirection();

Et encore, vous devez ~~danser pour~~ établir un réglage spécial avant de créer un canal gRpc. Cela ne peut être effectué qu'une seule fois lors du lancement de l'application. Par conséquent, je l'ai ajouté à peu près au même endroit que la ligne supprimée mentionnée ci-dessus. Cela ne devrait être appelé que pour HTTP.

AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);

Caractéristiques de configuration pour HTTPS

Il y a quelques difficultés à travailler avec SSL sur Windows et Linux. Il peut arriver que vous développiez sur un ordinateur Windows et déployiez sur Docker / Kubernetes à l'aide d'images basées sur Linux. Dans ce cas, la configuration n'est pas aussi simple que celle décrite dans de nombreux articles. Je décrirai cette configuration dans un autre article, et ici je ne toucherai qu'au code.

Nous devons reconfigurer le canal gRpc pour utiliser les informations d'identification SSL. Si vous déployez sur Docker et créez des images basées sur Linux, vous devrez peut-être également configurer HttpClient pour autoriser les certificats non valides. HttpClient est créé pour chaque canal.

httpClientBuilder.ConfigureChannel(o =>
{
    // add SSL credentials
    o.Credentials = new SslCredentials();
    // allow invalid/untrusted certificates
    var httpClientHandler = new HttpClientHandler
    {
        ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
    };
    var httpClient = new HttpClient(httpClientHandler);
    o.HttpClient = httpClient;
});

Ajout d'en-têtes HTTP

Les en-têtes sont ajoutés dans la classe d'intercepteur (successeur d' Interceptor ). gRpc utilise le concept de métadonnées, qui est envoyé avec les demandes comme en-têtes. La classe d'intercepteur doit ajouter des métadonnées pour le contexte d'appel.

public class AuthHeadersInterceptor : Interceptor
{
    public AuthHeadersInterceptor(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }
    
    public override AsyncUnaryCall<TResponse> AsyncUnaryCall<TRequest, TResponse>(TRequest request, ClientInterceptorContext<TRequest, TResponse> context, AsyncUnaryCallContinuation<TRequest, TResponse> continuation)
    {
        var metadata = new Metadata
        {
            {HttpHeaderNames.Authorization, $"Bearer <JWT_TOKEN>"}
        };
        var userIdentity = _httpContextAccessor.HttpContext.User.Identity;
        if (userIdentity.IsAuthenticated)
        {
            metadata.Add(HttpHeaderNames.User, userIdentity.Name);
        }
        var callOption = context.Options.WithHeaders(metadata);
        context = new ClientInterceptorContext<TRequest, TResponse>(context.Method, context.Host, callOption);
        
        return base.AsyncUnaryCall(request, context, continuation);
    }
}

Pour le scénario, lorsque vous appelez simplement le service gRpc, vous devez uniquement remplacer la méthode AsyncUnaryCall . Bien sûr, le jeton JWT peut être enregistré dans des fichiers de configuration.

Et c'est tout. Plus tard, j'ajouterai un lien vers le code avec un exemple simple du cas d'utilisation décrit. Si vous avez d'autres questions, écrivez-moi. Je vais essayer de répondre.