Bunnynut
Bunnynut

Reputation: 1328

How to mock Jwt bearer token for integration tests

I have created a microservice using .Net 5 which has some endpoints which can only be called with a jwtBearertoken.

The ConfigureServices and Configure methods in the StartUp class look like this:

        public void ConfigureServices(IServiceCollection services)
    {
        ConfigureDatabaseServices(services);
        ConfigureMyProjectClasses(services);
        services.AddVersioning();

        services.AddControllers();
        services.AddAuthentication(_configuration);
        // Add framework services.
        var mvcBuilder = services
            .AddMvc()
            .AddControllersAsServices();
        ConfigureJsonSerializer(mvcBuilder);
    }

        public void Configure(
        IApplicationBuilder app,
        IWebHostEnvironment webEnv,
        ILoggerFactory loggerFactory,
        IHostApplicationLifetime applicationLifetime)
    {
        _logger = loggerFactory.CreateLogger("Startup");

        try
        {
            app.Use(async (context, next) =>
            {
                var correlationId = Guid.NewGuid();
                System.Diagnostics.Trace.CorrelationManager.ActivityId = correlationId;
                context.Response.Headers.Add("X-Correlation-ID", correlationId.ToString());
                await next();
            });

            app.UseRouting();
            app.UseAuthentication();
            app.UseAuthorization();

            app.UseEndpoints(endpoints => { endpoints.MapControllers(); });
            applicationLifetime.ApplicationStopped.Register(() =>
            {
                LogManager.Shutdown();
            });
        }
        catch (Exception e)
        {
            _logger.LogError(e.Message);
            throw;
        }
    }

AuthenticationExtensions:

    public static class AuthenticationExtensions
    {
    public static void AddAuthentication(this IServiceCollection services, IConfiguration configuration)
    {
        services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options     =>
        {
            options.Authority = configuration["Authorization:Authority"];
            options.TokenValidationParameters = new TokenValidationParameters
            {
                ValidateAudience = false
            };
        });
    }
}

I'm using an authorization server for the microservice to validate the token.

After adding an [Authorize] attribute above the controllers postman returns 401 Unauthorized and the integration tests I had created before adding Authentication also return Unauthorized as expected. Now I am trying to figure out how I can change my integration tests by adding a JwtBearerToken and mocking the response from the authorization server so my tests will pass again. How can I achieve this?

Upvotes: 5

Views: 19925

Answers (1)

S. ten Brinke
S. ten Brinke

Reputation: 2973

My answer is not 100% integrated, because we will add an extra auth scheme. TL;DR: You are not testing if your auth works, but working around it.

It would be best to use an ACTUAL token, but perhaps this solution is a nice middle ground.

You could create another auth scheme like DevBearer where you can specify an account, for example if you send the auth header DevBearer Customer-John, the application would recognize you as Customer John.

I use this approach during development because it is very easy to just test different users quickly. My code looks something like this:

Startup.Auth.cs

        private void ConfigureAuthentication(IServiceCollection services)
        {
            services.AddHttpContextAccessor();

            services
                    .AddAuthentication(options =>
                    {
                        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
                    })
                    .AddJwtBearer(options =>
                    {
                        options.Audience = "Audience";
                        options.Authority = "Authority";
                    });

#if DEBUG
            if (Environment.IsDevelopment())
            {
                AllowDevelopmentAuthAccounts(services);
                return;
            }
#endif

            // This is custom and you might need change it to your needs.
            services.AddAuthorization();

        }


#if DEBUG
        // If this is true, you can use the Official JWT bearer login flow AND Development Auth Account (DevBearer) flow for easier testing.
        private static void AllowDevelopmentAuthAccounts(IServiceCollection services)
        {
            services.AddAuthentication("DevBearer").AddScheme<DevelopmentAuthenticationSchemeOptions, DevelopmentAuthenticationHandler>("DevBearer", null);

            // This is custom and you might need change it to your needs.
            services.AddAuthorization();
        }
#endif

Custom Policies Hint

// Because my Policies/Auth situation is different than yours, I will only post a hint that you might want to use.
// I want to allow calls from the REAL flow AND DevBearer flow during development so I can easily call my API using the DevBearer flow, or still connect it to the real IDentityServer and front-end for REAL calls.

                var policyBuilder = new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme).RequireAuthenticatedUser();

                // The #IF adds an extra "security" check so we don't accidentally activate the development auth flow on production
#if DEBUG
                if (_allowDevelopmentAuthAccountCalls)
                {
                    policyBuilder.AddAuthenticationSchemes("DevBearer").RequireAuthenticatedUser();
                }
#endif

                return policyBuilder;

Auth handler

#if DEBUG
using System;
using System.Collections.Generic;
using System.Net.Http.Headers;
using System.Security.Claims;
using System.Text.Encodings.Web;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Authentication;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;

namespace NAMESPACE
{
    public class DevelopmentAuthenticationHandler : AuthenticationHandler<DevelopmentAuthenticationSchemeOptions>
    {
        public DevelopmentAuthenticationHandler(
            IOptionsMonitor<DevelopmentAuthenticationSchemeOptions> options,
            ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock)
            : base(options, logger, encoder, clock)
        {
        }

        protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
        {
            if (!Context.Request.Headers.TryGetValue("Authorization", out var authorizationHeader))
            {
                return AuthenticateResult.Fail("Unauthorized");
            }

            var auth = AuthenticationHeaderValue.Parse(authorizationHeader);

            if (auth.Scheme == "Bearer")
            {
                // If Bearer is used, it means the user wants to use the REAL authentication method and not the development accounts. 
                return AuthenticateResult.Fail("Bearer requests should use the real JWT validation scheme");
            }

            // Dumb workaround for NSwag/Swagger: I can't find a way to make it automatically pass "DevBearer" in the auth header.
            // Having to type DevBearer everytime is annoying. So if it is missing, we just pretend it's there.
            // This means you can either pass "ACCOUNT_NAME" in the Authorization header OR "DevBearer ACCOUNT_NAME".
            if (auth.Parameter == null)
            {
                auth = new AuthenticationHeaderValue("DevBearer", auth.Scheme);
            }

            IEnumerable<Claim> claims;
            try
            {
                var user = auth.Parameter;
                claims = GetClaimsForUser(user);
            }
            catch (ArgumentException e)
            {
                return AuthenticateResult.Fail(e);
            }

            var identity = new ClaimsIdentity(claims, "DevBearer");
            var principal = new ClaimsPrincipal(identity);

            // Add extra claims if you want to
            await Options.OnTokenValidated(Context, principal);

            var ticket = new AuthenticationTicket(principal, "DevBearer");

            return AuthenticateResult.Success(ticket);
        }

        private static IEnumerable<Claim> GetClaimsForUser(string? user)
        {
            switch (user?.ToLowerInvariant())
            {
                // These all depend on your needs.
                case "Customer-John":
                    {
                        yield return new("ID_CLAIM_NAME", Guid.Parse("JOHN_GUID_THAT_EXISTS_IN_YOUR_DATABASE").ToString(), ClaimValueTypes.String);
                        yield return new("ROLE_CLAIM_NAME", "Customer", ClaimValueTypes.String);
                        break;
                    }
                default:
                    {
                        throw new ArgumentException("Can't set specific account for local development because the user is not recognized", nameof(user));
                    }
            }
        }
    }

    public class DevelopmentAuthenticationSchemeOptions : AuthenticationSchemeOptions
    {
        public Func<HttpContext, ClaimsPrincipal, Task> OnTokenValidated { get; set; } = (context, principal) => { return Task.CompletedTask; };
    }
}
#endif

With something like this, you could do an API call with an authorization header like DevBearer Customer-John and it would add the ID and role claim to the context, allowing auth to succeed :)

Upvotes: 7

Related Questions