JWT authentication with ASP.NET Core

In a previous post, I've written about using cookie authentication for an ASP.NET Core web site. Authenticating user by using a cookie is common for a web site. However, for an API, it's more common to use a token for authentication. Json Web Token (JWT) is a way to create and validate a token. In this post, we'll see how to use JWT with ASP.NET Core to authenticate the users. While the client can be any kind of application, I'll use a front-end application with JavaScript/TypeScript.

What's Json Web Token (JWT)

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA. https://jwt.io/introduction

JWTs consist of 3 parts:

  • The header contains the type of the token (JWT) and the algorithm used to sign it
  • The payload contains the list of claims. Claims can be of 3 types: predefined claims (issuer, subject, expiration date, etc.), public claims (defined in the IANA JWT registry), and private claims (custom names)
  • The signature is used to verify the message wasn't changed along the way

To create the JWT, the three parts are encoded in base64 and separated by a dot. Here's the header and the payload of a JWT:

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "meziantou",
  "iss": "meziantou.net"
}

This token is encoded in this form:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJtZXppYW50b3UiLCJpc3MiOiJtZXppYW50b3UubmV0In0.LR3RSg_y4xtsvc7vnKh3JXySCQtEsSNo4xkDBW9J2r4

Then, you can use it to authenticate by using the Authorization header:

Authorization: bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJtZXppYW50b3UiLCJpc3MiOiJtZXppYW50b3UubmV0In0.LR3RSg_y4xtsvc7vnKh3JXySCQtEsSNo4xkDBW9J2r4

Note that the authority that deliver the token and the one that validate the token may be differents. The only requirement is to be able to validate the signature, so you are sure the token is generated by the trusted authority.

Now, you have a better understanding of what is Json Web Token. Let's create an ASP.NET Core application that uses JWT to authenticate users!

Prerequisites - Generate a secret key

To create and validate a token, you must use a secret key. From the following Information Security Stack Exchange post, the length of the key should be 256 bits for the HmacSha256 algorithm (read carefully this thread because it may change depending on the algorithm). Using .NET it's very easy to generate a random key. Create a console application and copy the following code:

public static void Main(string[] args)
{
    var rng = System.Security.Cryptography.RandomNumberGenerator.Create();
    var bytes = new byte[256 / 8];
    rng.GetBytes(bytes);
    Console.WriteLine(Convert.ToBase64String(bytes));
}

Then, you can store the generated key in the configuration file of your ASP.NET Core web site. Open the appsettings.json file and add the following section:

{
  "JwtAuthentication": {
    "SecurityKey": "ouNtF8Xds1jE55/d+iVZ99u0f2U6lQ+AHdiPFwjVW3o=",
    "ValidAudience": "https://localhost:44318/",
    "ValidIssuer": "https://localhost:44318/"
  }
}

Finally, you can register the configuration in the service collection to retrieve these settings easily:

using Microsoft.IdentityModel.Tokens;

public class JwtAuthentication
{
    public string SecurityKey { get; set; }
    public string ValidIssuer { get; set; }
    public string ValidAudience { get; set; }

    public SymmetricSecurityKey SymmetricSecurityKey => new SymmetricSecurityKey(Convert.FromBase64String(SecurityKey));
    public SigningCredentials SigningCredentials => new SigningCredentials(SymmetricSecurityKey, SecurityAlgorithms.HmacSha256);
}

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
        services.Configure<JwtAuthentication>(Configuration.GetSection("JwtAuthentication"));
    }
}

By the way, it can be a good idea to look at Azure Key Vault, AWS KMS or their competitors to store this secret key.

Generate a token for a user

The first part is to generate a token for a client. Before issuing a token, you must validate the user is valid. In this sample we'll use a dummy validation. In your application, you should consider using ASP.NET Core Identity or a similar solution to handle users and validate password.

public class UserController : Controller
{
    private readonly IOptions<JwtAuthentication> _jwtAuthentication;

    public UserController(IOptions<JwtAuthentication> jwtAuthentication)
    {
        _jwtAuthentication = jwtAuthentication ?? throw new ArgumentNullException(nameof(jwtAuthentication));
    }

    [HttpPost]
    [AllowAnonymous]
    public IActionResult GenerateToken([FromBody]GenerateTokenModel model)
    {
        // TODO use your actual logic to validate a user
        if (model.Password != "654321")
            return BadRequest("Username or password is invalid");

        var token = new JwtSecurityToken(
            issuer: jwtAuthentication.ValidIssuer,
            audience: jwtAuthentication.ValidAudience,
            claims: new[]
            {
                // You can add more claims if you want
                new Claim(JwtRegisteredClaimNames.Sub, model.Username),
                new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
            },
            expires: DateTime.UtcNow.AddDays(30),
            notBefore: DateTime.UtcNow,
            signingCredentials: _jwtAuthentication.Value.SigningCredentials);

        return Ok(new
        {
            token = new JwtSecurityTokenHandler().WriteToken(token)
        });
    }

    public class GenerateTokenModel
    {
        [Required]
        public string Username { get; set; }
        [Required]
        public string Password { get; set; }
    }
}

Authenticate the user on the server

The next part is to authenticate the user using the token. ASP.NET Core already contains everything for that. It will get the value of the Authorization header and parse its value. Then, it will check the token is valid.

First, you need to protect your action from anonymous user. You can use the Authorize with the Bearer scheme:

public class SampleController : Controller
{
    [Authorize(JwtBearerDefaults.AuthenticationScheme)]
    public IActionResult Get()
    {
        return Ok();
    }
}

In the startup.cs file, add the following code to register the JWT authentication handler:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        // [...]

        services.Configure<JwtAuthentication>(Configuration.GetSection("JwtAuthentication"));

        // I use PostConfigureOptions to be able to use dependency injection for the configuration
        // For simple needs, you can set the configuration directly in AddJwtBearer()
        services.AddSingleton<IPostConfigureOptions<JwtBearerOptions>, ConfigureJwtBearerOptions>();
        services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
            .AddJwtBearer();
    }

    private class ConfigureJwtBearerOptions : IPostConfigureOptions<JwtBearerOptions>
    {
        private readonly IOptions<JwtAuthentication> _jwtAuthentication;

        public ConfigureJwtBearerOptions(IOptions<JwtAuthentication> jwtAuthentication)
        {
            _jwtAuthentication = jwtAuthentication ?? throw new System.ArgumentNullException(nameof(jwtAuthentication));
        }

        public void PostConfigure(string name, JwtBearerOptions options)
        {
            var jwtAuthentication = _jwtAuthentication.Value;

            options.ClaimsIssuer = jwtAuthentication.ValidIssuer;
            options.IncludeErrorDetails = true;
            options.RequireHttpsMetadata = true;
            options.TokenValidationParameters = new TokenValidationParameters
            {
                ValidateActor = true,
                ValidateIssuer = true,
                ValidateAudience = true,
                ValidateLifetime = true,
                ValidateIssuerSigningKey = true,
                ValidIssuer = jwtAuthentication.ValidIssuer,
                ValidAudience = jwtAuthentication.ValidAudience,
                IssuerSigningKey = jwtAuthentication.SymmetricSecurityKey,
                NameClaimType = ClaimTypes.NameIdentifier
            };
        }
    }
}

The website is now ready. You can generate a token and use this token to authenticate the users. It's time to create a client. Let's create a JavaScript client.

JavaScript Client

First, you need to generate a token for the current user. The request is a POST that contains your username and password.

Note: the url may be different in your context

 const response = await fetch("/user/generatetoken", {
        method: "POST",
        body: JSON.stringify({
            username: "foo@bar",
            password: "654321"
        }),
        headers: {
            "Content-Type": "application/json",
            "Accept": "application/json"
        }
    });
const json = await response.json();
const token = json.token;
console.log(token);

Then, you can use this token. In each request, you must add the Authorization header with the token. Here's the code:

const response = await fetch("/sample", {
        method: "GET",
        headers: {
            "Authorization": "Bearer " + token, // Add the authentication header
            "Accept": "application/json"
        },
        credentials: "include"
    });
console.log(response.ok);

It's so easy using the fetch API 😃

Protecting the whole website / api

This part is optional.

If you want the users to be authenticated to access the API, you can decorate all the controllers with the [Authorize] attribute. But, this is not very convenient. Instead, you can apply the attribute globally using an authorization policy. Open the Startup.cs file and change the ConfigureService method to add the policy.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc(config =>
    {
        var policy = new AuthorizationPolicyBuilder()
            .AddAuthenticationSchemes(JwtBearerDefaults.AuthenticationScheme)
            .RequireAuthenticatedUser()
            .Build();
        config.Filters.Add(new AuthorizeFilter(policy));
    });
}

You can read more about authorization policy in the documenation

Security considerations

It's strongly recommended to use HTTPS for your web api. The JWT token is like the username/password of the user. So, you must prevent man-in-the-middle attack. It's very easy to get a free certificate with Let's Encrypt.

The RFC7518 section 8 contains many security considerations dependant on the used algorithms. You should read them before implementing JWT to be sure to follow the best practices.

JWT is signed and encoded only, not encrypted. This means you should not store sensitive information into it, because anyone with the token can read the data. You can check the content of a token using https://jwt.io

Conclusion

Using JWT authentication with an ASP.NET Core application is pretty easy. In a few lines of code, you can add it to your web api. You can see the JWT authentication in action in my PasswordManager application.

Filter Application Insights events in ASP.NET Core

Application Insights ingests lots of data: requests, traces, events, metrics, etc. If your web site has lots of users, the amount of data can be huge. This mean you pay for this data. While Application Insights is cheap, you may want to reduce the bill. One way is to sample the data. In short, you send only xx% of the events. This is the simplest solution. The other solution is to filter low value events for your usage. For instance, if you use Application Insights to diagnose errors, you may want to filter success requests.

The Application Insights SDK provides an interface to manipulate the telemetry events: ITelemetryProcessor. This interface allows to change the events, for instance to add a property or remove sensible data. If also allow to filter the event. Telemetry processors are chained. Each telemetry processor handle the event and pass it to the next processor. A telemetry processor can also choose to discard the event by not sending it to the next processor. We'll use this to filter the events.

First, create a class that implements ITelemetryProcessor. This class will filter request events with status code 200.

public class MyTelemetryProcessor : ITelemetryProcessor
{
    private ITelemetryProcessor _next;

    public MyTelemetryProcessor(ITelemetryProcessor next)
    {
        // Next TelemetryProcessor in the chain
        _next = next;
    }

    public void Process(ITelemetry item)
    {
        if (item is RequestTelemetry request)
        {
            if (request.ResponseCode == "200")
            {
                // Filter the event
                return;
            }
        }

        // Send the item to the next TelemetryProcessor
        _next.Process(item);
    }
}

Then, you have to configure Application Insights to use the MyTelemetryProcessor. In the Startup.cs file, add the following code in the Configure method:

public void Configure(IApplicationBuilder app)
{
    var configuration = app.ApplicationServices.GetService<TelemetryConfiguration>();
    configuration.TelemetryProcessorChainBuilder.Use(next => new MyTelemetryProcessor(next));
    configuration.TelemetryProcessorChainBuilder.Build();

    // ...
}

You filter is now configured and active. Now you can customize the filter to remove other kind of events. For instance, you can remove some specific traces based on their category:

public void Process(ITelemetry item)
{
    if (item is TraceTelemetry trace)
    {
        if (trace.Properties.TryGetValue("CategoryName", out var category) &&
            category == "Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware")
        {
            return;
        }
    }

    _next.Process(item);
}

If you have a public website, you may have lots of requests to the WordPress login page /wp-login.php. If you are not using a WordPress website, you can filter those events:

public void Process(ITelemetry item)
{
    if (item is RequestTelemetry request)
    {
        // The url is not handled, so 404
        if (string.Equals(request.ResponseCode, "404", StringComparison.Ordinal))
        {
            var path = request.Url?.AbsolutePath;
            if (path != null && path.EndsWith("/wp-login.php", StringComparison.OrdinalIgnoreCase))
            {
                return;
            }
        }
    }

    Next.Process(item);
}

Conclusion

The Application Insights SDK allows you to control the data sent to Azure. You can augment events with custom data, edit the events to remove sensitive data, or filter unneeded events. So, you can better detect & diagnose issues and understand usage for your web apps.

Testing an ASP.NET Core application using TestServer

When Microsoft has designed ASP.NET Core, testing was clearly part of the design. Using dependency injection, you can unit test your middlewares and controllers. But you can also use the TestServer to make integration tests. This means you can test your full web application without an IIS server or any external thing. It's a fully in process server. A simple example will be much clearer. Let's use the following controller:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        app.UseMvc();
    }
}

[Route("api/[controller]")]
public class ValuesController : Controller
{
    [HttpGet]
    public IEnumerable<string> Get()
    {
        return new string[] { "value1", "value2" };
    }
}
  1. Add a new MSTest project
  2. Add a reference to the web project
  3. Add the NuGet package: Microsoft.AspNetCore.TestHost
  4. Create a test
[TestClass]
public class Tests
{
    [TestMethod]
    public async Task TestMethod1()
    {
        var webHostBuilder =
              new WebHostBuilder()
                    .UseEnvironment("Test") // You can set the environment you want (development, staging, production)
                    .UseStartup<Startup>(); // Startup class of your web app project

        using (var server = new TestServer(webHostBuilder))
        using (var client = server.CreateClient())
        {
            string result = await client.GetStringAsync("/api/values");
            Assert.AreEqual("[\"value1\",\"value2\"]", result);
        }
    }
}

This was a basic example. In a more complex scenario, you may want to replace some service using DI. ASP.NET provides mecanisms to support multiple environments. For instance, you can create one Configure<Environment name>Services method per environment. If no method is defined for the environment, the ConfigureServices will be used. One way to personalize the DI for testing is to create a class that inherits from Startup and add the method ConfigureTestServices:

public class TestStartup : Startup
{
    public TestStartup(IHostingEnvironment env) : base(env)
    {
    }

    public void ConfigureTestServices(IServiceCollection services)
    {
        // Configure services for Test environment
    }
}

Then, use the TestStartup class to initialize the TestServer:

[TestMethod]
public async Task TestMethod1()
{
    var webHostBuilder =
            new WebHostBuilder()
                .UseEnvironment("Test")
                .UseStartup<TestStartup>();
    // ...
}

Test Explorer

This was just a quick introduction to integration testing with ASP.NET Core. You can find more resources in the documentation.

Validating user with cookie authentication in ASP.NET Core 2

In a previous post, I wrote about the cookie authentication in ASP.NET Core 2. The cookie authentication does 2 things:

  • Write a cookie with encrypted data when the user logs in
  • Read the cookie, decrypt it, and set the request identity (Request.User.Identity)

When it read the cookie and set the identity, it doesn't check the user actually exists. For instance, John logs in on browser A, then, he deletes his account on computer B. When he goes back to the website on browser A, the cookie is still valid, while his account doesn't exist anymore in the database. If you don't care, you may think the user is logged in, whereas it shouldn't.

Of course, the cookie authentication has a hook to validate the user and prevent this kind of situation. Let's see how to use it.

First, you need to handle the OnValidatePrincipal method in the ConfigureServices method:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(options =>
    {
        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    })
        .AddCookie(options =>
        {
            options.Events.OnValidatePrincipal = PrincipalValidator.ValidateAsync;
        });
}

Then, you can check the principal corresponds to an actual user. In case the user is invalid, you can prevent the user from being authenticated by calling the RejectPrincipal method. The validation logic is depend of your application. So, the following code is just an example:

public static class PrincipalValidator
{
    public static async Task ValidateAsync(CookieValidatePrincipalContext context)
    {
        if (context == null) throw new System.ArgumentNullException(nameof(context));

        var userId = context.Principal.Claims.FirstOrDefault(claim => claim.Type == ClaimTypes.NameIdentifier)?.Value;
        if (userId == null)
        {
            context.RejectPrincipal();
            return;
        }

        // Get an instance using DI
        var dbContext = context.HttpContext.RequestServices.GetRequiredService<IdentityDbContext>();
        var user = await dbContext.Users.FindByIdAsync(userId);
        if (user == null)
        {
            context.RejectPrincipal();
            return;
        }
    }
}

The cookie authentication is very easy to use. However, authentication is not as easy as you think. It's very easy to forget something, and get unexpected behaviors.

Use brotli compression with ASP.NET Core

Brotli is a compression algorithm. In general, it provides better compression results than gzip. For instance, the size of the default page of an ASP.NET Core project using gzip is 1797 bytes, and using Brotli, it's only 1333 bytes. So it's a 25% reduction!

You can use Brotli with most of the major browsers (source):

Brotli browser support

So, it's time to support Brotli in addition to gzip!

I've already written about the gzip compression in ASP.NET Core using the ReponseCompression package: Enabling gzip compression with ASP.NET Core. Today, we'll see how to provide your own compression method, and support brotli.

Implementation

If you check the code in the CoreFX Lab repository on GitHub regulary, you may have notice there is a new project: System.IO.Compression.Brotli. This project contains an API to compress and decompress data using the Brotli algorithm. Of course, this package is a preview, and is not supported yet.

CoreFx Lab projects are not published to NuGet.org. Instead, there are published to a public MyGet repository. So, to get this package, you must declare the feed in Visual Studio:

https://dotnet.myget.org/F/dotnet-corefxlab/api/v3/index.json

Or, you can create a nuget.config at the root of the solution with the following content:

<configuration>
  <packageSources>
    <add key="dotnet-corefxlab" value="https://dotnet.myget.org/F/dotnet-corefxlab/" />
  </packageSources>
</configuration>

Then, you can add the 2 following packages:

  • System.IO.Compression.Brotli
  • Microsoft.AspNetCore.ResponseCompression

The response compression middleware look at the headers of the request and check if a compression provider can handle one of the accepted encoding. By default, only the gzip algorithm is supported. You can support custom encodings by implementing a custom compression provider. A custom provider must implement the ICompressionProvider interface. This interface contains a property with the name of the encoding, and a method to create a compression stream. The brotli package provide a BrotliStream class, so the implementation is very easy:

public class BrotliCompressionProvider : ICompressionProvider
{
    public string EncodingName => "br";
    public bool SupportsFlush => true;

    public Stream CreateStream(Stream outputStream)
    {
        return new BrotliStream(
            outputStream,
            CompressionMode.Compress,
            leaveOpen: false,
            bufferSize: 65520,
            quality: CompressionLevel.Optimal); // very costly, may not be appropriate for a web server
    }
}

Finally, you can use the custom provider:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();

        services.AddResponseCompression(options =>
        {
            options.Providers.Add(new BrotliCompressionProvider());
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseResponseCompression();
        app.UseStaticFiles();
        app.UseMvcWithDefaultRoute();
    }
}

You can check the server compress the response using brotli by looking at the response header:

Conclusion

The Brotli compression package is in preview, and not ready to go in production. So, use it with caution. However, this is another example of how easy it is to extend ASP.NET Core 😃 Plus, you should really monitor the corefx repository on GitHub. You may find some gems such as the Brotli compression project.