Let's add a private members region, wrapping the existing _next variable and adding the following (new lines highlighted):

#region private members 
private readonly RequestDelegate _next; 
 
// JWT-related members

private TimeSpan TokenExpiration;

private SigningCredentials SigningCredentials;

// EF and Identity members, available through DI

private ApplicationDbContext DbContext;

private UserManager<ApplicationUser> UserManager;

private SignInManager<ApplicationUser> SignInManager;

#endregion Private Members

Don't forget to add the required namespaces as well at the beginning of the file:

using Microsoft.IdentityModel.Tokens; 
using Microsoft.AspNetCore.Identity; 
using OpenGameListWebApp.Data.Users; 
using OpenGameListWebApp.Data; 
using System.Text; 

As we can see, we're defining a number of variables here that we'll be using internally. Most of them will be instantiated in the constructor, either programmatically or by using the dependency injection pattern we've already used several times.

This region includes the minimum amount of info needed to sign in using a JWT token: a SecurityKey and an Issuer. We also define a TokenEndPoint here, which is the URL path that we will use to process the incoming authentication login requests. To put it in other words, it's the route that the JwtProvider will have to intercept (right before the standard MVC routing strategy) to properly handle the login requests:

#region Static Members 
private static readonly string PrivateKey = "private_key_1234567890"; 
public static readonly SymmetricSecurityKey SecurityKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(PrivateKey)); 
public static readonly string Issuer = "OpenGameListWebApp"; 
public static string TokenEndPoint = "/api/connect/token"; 
#endregion Static Members 

Notice that most of these static members have the public access modifier. That's because we'll be using them outside of this class when we'll have to configure the token verification middleware.

Here's what the Constructor region looks like:

#region Constructor
public JwtProvider(
    RequestDelegate next,
    ApplicationDbContext dbContext,
    UserManager<ApplicationUser> userManager,
    SignInManager<ApplicationUser> signInManager)
{
    _next = next;

    // Instantiate JWT-related members
    TokenExpiration = TimeSpan.FromMinutes(10);
    SigningCredentials =  new SigningCredentials(SecurityKey, SecurityAlgorithms.HmacSha256);

    // Instantiate through Dependency Injection
    DbContext = dbContext;
    UserManager = userManager;
    SignInManager = signInManager;
}
#endregion Constructor

Here, we define the JWT token expiration time and encrypt the symmetrical security key that will be used to validate JWTs using a standard HmacSha256 encryption algorithm. We're also instantiating the EF/Identity members through DI, like we have done a number of times.

Let's move to the Invoke method, which we conveniently wrapped inside the public methods region:

#region public methods 
public Task Invoke(HttpContext httpContext) 
{ 
   // Check if the request path matches our TokenEndPoint 
   if (!httpContext.Request.Path.Equals(TokenEndPoint, StringComparison.Ordinal)) return _next(httpContext); 
 
  // Check if the current request is a valid POST with the appropriate content type (application/x-www-form-urlencoded) 
  if (httpContext.Request.Method.Equals("POST") && httpContext.Request.HasFormContentType) 
  { 
      // OK: generate token and send it via a json-formatted string 
      return CreateToken(httpContext); 
  } 
  else 
 { 
      // Not OK: output a 400 - Bad request HTTP error. 
      httpContext.Response.StatusCode = 400; 
      return httpContext.Response.WriteAsync("Bad request."); 
  } 
} 
#endregion public methods 

Here, we need to check whether the request path matches the chosen login path. If it does, we continue execution, otherwise we entirely skip the request. Right after that, we need to check whether the current request is a valid form-urlencoded  POST. If that's the case, we call the CreateToken internal method; otherwise, we return a 400 error response.

The CreateToken method is where most of the magic takes place. We check the given username and password against our internal Identity database and, depending on the result, generate and return either a JWT token or an appropriate error response:

#region Private Methods
private async Task CreateToken(HttpContext httpContext)
{
    try
    {
        // retrieve the relevant FORM data
        string username = httpContext.Request.Form["username"];
        string password = httpContext.Request.Form["password"];

        // check if there's an user with the given username
        var user = await UserManager.FindByNameAsync(username);
        // fallback to support e-mail address instead of username
        if (user == null && username.Contains("@")) user = await UserManager.FindByEmailAsync(username);

        var success = user != null && await UserManager.CheckPasswordAsync(user, password);
         if (success)
         {
             DateTime now = DateTime.UtcNow;

             // add the registered claims for JWT (RFC7519).
             // For more info, see https:
             //tools.ietf.org/html/rfc7519#section-4.1
             var claims = new[] {
             new Claim(JwtRegisteredClaimNames.Iss, Issuer),
             new Claim(JwtRegisteredClaimNames.Sub, user.Id),
             new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
             new Claim(JwtRegisteredClaimNames.Iat, new DateTimeOffset(now).ToUnixTimeSeconds().ToString(), ClaimValueTypes.Integer64)
             // TODO: add additional claims here
         };

         // Create the JWT and write it to a string
         var token = new JwtSecurityToken(
         claims: claims,
         notBefore: now,
         expires: now.Add(TokenExpiration),
         signingCredentials: SigningCredentials);
         var encodedToken = new JwtSecurityTokenHandler().WriteToken(token);

         // build the json response
         var jwt = new {
             access_token = encodedToken,
             expiration = (int)TokenExpiration.TotalSeconds
         };

         // return token
         httpContext.Response.ContentType = "application/json";
         await httpContext.Response.WriteAsync(JsonConvert.SerializeObject(jwt));
         return;
        }
      }
    catch (Exception ex)
    {
        // TODO: handle errors
        throw ex;
    }

    httpContext.Response.StatusCode = 400;
    await httpContext.Response.WriteAsync("Invalid username or password.");
}
#endregion Private Methods

This will also require the following namespace references:

using System.IdentityModel.Tokens.Jwt; 
using System.Security.Claims; 
using Newtonsoft.Json; 

The code is pretty much self-documented using some inline comments indicating what we're doing here and there. We can see how the username and password are retrieved from the HttpContext and checked using the AspNetCore.Identity UserManager class; if the user exists, we issue a JSON-formatted object containing a JWT token and its expiration time, otherwise we return a HTTP 400 error.

The sample code provided for middleware classes includes a handy extension method that we can use to add our newborn provider to the request pipeline. We don't need to change it, so we'll just wrap it in an extension methods region:

#region Extension Methods
// Extension method used to add the middleware to the HTTP request pipeline.
public static class JwtProviderExtensions
{
    public static IApplicationBuilder UseJwtProvider(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<JwtProvider>();
    }
}
#endregion Extension Methods

Here's how our JwtProvider class will look after all this hard work:

using System; 
using System.Text; 
using System.Threading.Tasks; 
using Microsoft.AspNetCore.Builder; 
using Microsoft.AspNetCore.Http; 
using Microsoft.IdentityModel.Tokens; 
using OpenGameListWebApp.Data; 
using Microsoft.AspNetCore.Identity; 
using OpenGameListWebApp.Data.Users; 
using System.IdentityModel.Tokens.Jwt; 
using System.Security.Claims; 
using Newtonsoft.Json; 
 
namespace OpenGameListWebApp.Classes 
{ 
    public class JwtProvider 
    { 
        #region Private Members 
        private readonly RequestDelegate _next; 
 
        // JWT-related members 
        private TimeSpan TokenExpiration; 
        private SigningCredentials SigningCredentials; 
 
        // EF and Identity members, available through DI 
        private ApplicationDbContext DbContext; 
        private UserManager<ApplicationUser> UserManager; 
        private SignInManager<ApplicationUser> SignInManager; 
        #endregion Private Members 
 
        #region Static Members 
        private static readonly string PrivateKey = "private_key_1234567890"; 
        public static readonly SymmetricSecurityKey SecurityKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(PrivateKey)); 
        public static readonly string Issuer = "OpenGameListWebApp"; 
        public static string TokenEndPoint = "/api/connect/token"; 
        #endregion Static Members 
 
        #region Constructor 
        public JwtProvider( 
            RequestDelegate next,  
            ApplicationDbContext dbContext,  
            UserManager<ApplicationUser> userManager,  
            SignInManager<ApplicationUser> signInManager) 
        { 
            _next = next; 
 
            // Instantiate JWT-related members 
            TokenExpiration = TimeSpan.FromMinutes(10); 
            SigningCredentials =  new SigningCredentials(SecurityKey, SecurityAlgorithms.HmacSha256); 
 
            // Instantiate through Dependency Injection 
            DbContext = dbContext; 
            UserManager = userManager; 
            SignInManager = signInManager; 
        } 
        #endregion Constructor 
 
        #region Public Methods 
        public Task Invoke(HttpContext httpContext) 
        { 
            // Check if the request path matches our LoginPath 
            if (!httpContext.Request.Path.Equals(TokenEndPoint, StringComparison.Ordinal)) return _next(httpContext); 
 
            // Check if the current request is a valid POST with the appropriate content type (application/x-www-form-urlencoded) 
            if (httpContext.Request.Method.Equals("POST") && httpContext.Request.HasFormContentType) 
            { 
                // OK: generate token and send it via a json-formatted string 
                return CreateToken(httpContext); 
            } 
            else 
            { 
                // Not OK: output a 400 - Bad request HTTP error. 
                httpContext.Response.StatusCode = 400; 
                return httpContext.Response.WriteAsync("Bad request."); 
            } 
        } 
        #endregion Public Methods 
 
        #region Private Methods 
        private async Task CreateToken(HttpContext httpContext) 
        { 
            try 
            { 
                // retrieve the relevant FORM data 
                string username = httpContext.Request.Form["username"]; 
                string password = httpContext.Request.Form["password"]; 
 
                // check if there's an user with the given username 
                var user = await UserManager.FindByNameAsync(username); 
                // fallback to support e-mail address instead of username 
                if (user == null && username.Contains("@")) user = await UserManager.FindByEmailAsync(username); 
 
                var success = user != null && await UserManager.CheckPasswordAsync(user, password); 
                if (success) 
                { 
                    DateTime now = DateTime.UtcNow; 
 
                    // add the registered claims for JWT (RFC7519). 
                    // For more info, see https://tools.ietf.org/html/rfc7519#section-4.1 
                    var claims = new[] { 
                        new Claim(JwtRegisteredClaimNames.Iss, Issuer), 
                        new Claim(JwtRegisteredClaimNames.Sub, username), 
                        new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()), 
                        new Claim(JwtRegisteredClaimNames.Iat, new DateTimeOffset(now).ToUnixTimeSeconds().ToString(), ClaimValueTypes.Integer64) 
                        // TODO: add additional claims here 
                    }; 
 
                    // Create the JWT and write it to a string 
                    var token = new JwtSecurityToken( 
                        claims: claims, 
                        notBefore: now, 
                        expires: now.Add(TokenExpiration), 
                        signingCredentials: SigningCredentials); 
                    var encodedToken = new JwtSecurityTokenHandler().WriteToken(token); 
 
                    // build the json response 
                    var jwt = new { 
                        access_token = encodedToken, 
                        expiration = (int)TokenExpiration.TotalSeconds 
                    }; 
 
                    // return token 
                    httpContext.Response.ContentType = "application/json"; 
                    await httpContext.Response.WriteAsync(JsonConvert.SerializeObject(jwt)); 
                    return; 
                } 
            } 
            catch (Exception ex) 
            { 
                // TODO: handle errors 
            } 
 
            httpContext.Response.StatusCode = 400; 
            await httpContext.Response.WriteAsync("Invalid username or password."); 
        } 
        #endregion Private Methods 
    } 
 
    #region Extension Methods 
    // Extension method used to add the middleware to the HTTP request pipeline. 
    public static class JwtProviderExtensions 
    { 
        public static IApplicationBuilder UseJwtProvider(this IApplicationBuilder builder) 
        { 
            return builder.UseMiddleware<JwtProvider>(); 
        } 
    } 
    #endregion Extension Methods 
} 

As for the custom CSS classes, we can add them to our Scripts/less/style.less file:

.login-container { 
    max-width: 330px; 
    padding: 15px; 
    .form-login { 
        margin: 0 0 10px 20px; 
        .checkbox { 
            margin-bottom: 10px; 
        } 
        input { 
            margin-bottom: 10px; 
        } 
    } 
} 

Our renewed LoginComponent should compile just fine. However, if we try to run the app now, we would get a full-scale Angular 2 runtime error in the browser's console log:

Pretty scary, isn't it?

When we see something like that in Angular 2, it usually means that we're missing a required module. That's exactly the case. In order to use reactive forms classes, we need to open our /Scripts/app/app.module.ts file and append ReactiveFormsModule to the following existing import statement, near the beginning of the file:

import {FormsModule, ReactiveFormsModule} from "@angular/forms"; 

And also add it to the imports array as follows:

imports: [ 
    BrowserModule, 
    HttpModule, 
    FormsModule, 
    ReactiveFormsModule, 
    RouterModule, 
    AppRouting 
], 

Once done, our application will be able to run without errors.

Wait a minute...FormsModule has been there since Chapter 3, Angular 2 Components and Client-Side Routing! On top of that, we even used it to build the ItemDetailEditComponent form, which happens to work just fine! Why do we need ReactiveFormsModule now?

As a matter of fact, we don't; we could stick to the FormsModule and build another template-driven form just like the one we already did. As a matter of fact, since this is a tutorial application, we took the chance to use the alternative strategy provided by Angular 2 to build forms: the model-driven (or reactive) forms approach.

This clarification raises a predictable question: which one of them is better? The answer is not easy, as both techniques have their advantages. To keep it extremely simple, we can say that template-driven forms are generally simpler to pull off, but they're rather difficult to test and validate as they become complex; conversely, model-driven forms do have an harder learning curve but they usually perform better when dealing with large forms, as they allow us to unit test their whole validation logic.

Let's do a quick test right now. Hit F5 and click on the Login top navigation bar. We should be welcomed by something like this:

Let's now check the validators by hitting the Sign in button, leaving the input fields empty. We can see the two textboxes react accordingly, since they're both expecting a required value:

Finally, let's test the outcome JSON by filling up the input fields with some random values and pressing the Sign in button again:

That's it. It seems that our login form is working fine.

In order to test our new AuthService component, we need to hook it up to the AppModule and to the LoginComponent we created a short while ago.

Open the /Scripts/app/app.module.ts file and add the following import line between the AppRouting and ItemService lines:

import {AppRouting} from "./app.routing"; 
import {AuthService} from "./auth.service"; 
import {ItemService} from "./item.service"; 

Then scroll down to the providers array and add it there too:

providers: [ 
    AuthService, 
    ItemService 
], 

Once done, switch back to the Scripts/app/login.component.ts file and replace the content of the source code as follows (new/updated lines are highlighted):

import {Component} from "@angular/core"; 
import {FormBuilder, Validators} from "@angular/forms"; 
import {Router} from "@angular/router"; 
import {AuthService} from "./auth.service"; 
 
@Component({ 
    selector: "login", 
    template: ` 
    <div class="login-container"> 
      <h2 class="form-login-heading">Login</h2> 
      <div class="alert alert-danger" role="alert" *ngIf="loginError"><strong>Warning:</strong> Username or Password mismatch</div> 
      <form class="form-login" [formGroup]="loginForm" (submit)="performLogin($event)"> 
        <input formControlName="username" type="text" class="form-control" placeholder="Your username or e-mail address" required autofocus /> 
        <input formControlName="password" type="password" class="form-control" placeholder="Your password" required /> 
        <div class="checkbox"> 
          <label> 
            <input type="checkbox" value="remember-me"> 
            Remember me 
          </label> 
        </div> 
        <button class="btn btn-lg btn-primary btn-block" type="submit">Sign in</button> 
      </form> 
    </div> 
    ` 
}) 
 
export class LoginComponent { 
    title = "Login"; 
    loginForm = null; 
    loginError = false; 
 
    constructor( 
        private fb: FormBuilder, 

private router: Router,
  private authService: AuthService) { 
        this.loginForm = fb.group({ 
            username: ["", Validators.required], 
            password: ["", Validators.required] 
        }); 
    } 
 
    performLogin(e) { 
        e.preventDefault(); 
        var username = this.loginForm.value.username;

        var password = this.loginForm.value.password;

        this.authService.login(username, password)

            .subscribe((data) => {

                // login successful

                this.loginError = false;

                var auth = this.authService.getAuth();

                alert("Our Token is: " + auth.access_token);

                this.router.navigate([""]);

            },

            (err) => {

                console.log(err);

                // login failure

                this.loginError = true;

            }); 
    } 
} 

What we did here is pretty straightforward:

Let's run a quick test to see whether everything is working as expected. Hit F5, then navigate through the login view using the top navigation menu. Once there, fill in the login form with some incorrect data to test the Wrong Username or Password alert and left-click on the Sign in button:

Now, let's test a successful login attempt by filling in the form again, this time using the actual Admin user credentials as defined within the DbSeeder class:

Then, left-click on the Sign in button.

If everything has been set up properly, we should receive the following response:

If we see something like this, it means that our JwtProvider works!

All we need to do now is to find a way to put that token inside the headers of all our subsequent requests, so we can check the token validation as well and complete our authentication cycle.

Let's start by updating the main menu navigation bar. Open the Scripts/app/app.component.ts file and add the following import reference near the top:

import {AuthService} from "./auth.service";

Right after that, change the template section in the following way (new/updated lines are highlighted):

<nav class="navbar navbar-default navbar-fixed-top"> 
    <div class="container-fluid"> 
        <input type="checkbox" id="navbar-toggle-cbox"> 
        <div class="navbar-header"> 
            <label for="navbar-toggle-cbox" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#navbar" aria-expanded="false" aria-controls="navbar"> 
                <span class="sr-only">Toggle navigation</span> 
                <span class="icon-bar"></span> 
                <span class="icon-bar"></span> 
                <span class="icon-bar"></span> 
            </label> 
            <a class="navbar-brand" href="javascript:void(0)"> 
                <img alt="logo" src="/img/logo.svg" /> 
            </a> 
        </div> 
        <div class="collapse navbar-collapse" id="navbar"> 
            <ul class="nav navbar-nav"> 
                <li [class.active]="isActive([''])"> 
                    <a class="home" [routerLink]="['']">Home</a> 
                </li> 
                <li [class.active]="isActive(['about'])"> 
                    <a class="about" [routerLink]="['about']">About</a> 
                </li> 
                <li *ngIf="!authService.isLoggedIn()"
               [class.active]="isActive(['login'])">

                    <a class="login" [routerLink]="['login']">Login</a>
 
               </li>

                <li *ngIf="authService.isLoggedIn()">

                    <a class="logout" href="javascript:void(0)"
                    (click)="logout()">Logout</a>

                </li>

                <li *ngIf="authService.isLoggedIn()"
                [class.active]="isActive(['item/edit', 0])">

                    <a class="add" [routerLink]="['item/edit', 0]">Add New</a>

                </li> 
            </ul> 
        </div> 
    </div> 
</nav> 
<h1 class="header">{{title}}</h1> 
<div class="main-container"> 
    <router-outlet></router-outlet> 
</div> 

What we did here is pretty easy to understand:

In order to use the authService object, we also need to instantiate it through dependency injection within the class constructor, which is another thing we have to change (new/updated lines highlighted):

constructor(public router: Router, public authService: AuthService) { } 

Finally, we need to implement that logout() method we talked about earlier:

logout(): boolean { 
    // logs out the user, then redirects him to Welcome View. 
    if (this.authService.logout()) { 
        this.router.navigate([""]); 
    } 
    return false; 
} 

Nothing odd here, just a standard logout and redirect behavior to adopt when the user chooses to perform a logout.

The changes we applied to the AppComponent template should also be performed in the ItemDetailViewComponent templates as well. Open Scripts/app/item-detail-view.component.ts and add the import line:

import {AuthService} from "./auth.service"; 

Then move to the constructor and add the AuthService reference there for DI (new code highlighted):

constructor( 
    private authService: AuthService, 
    private itemService: ItemService, 
    private router: Router, 
    private activatedRoute: ActivatedRoute) { } 

And finally, update the template section accordingly, using the same ngIf built-in directive we used before to show/hide the Edit tab accordingly to the current user's logged in status:

<li *ngIf="authService.isLoggedIn()" role="presentation"> 
    <a href="javascript:void(0)" (click)="onItemDetailEdit(item)">Edit</a> 
</li> 

Testing the client

Let's hit F5 and see whether everything is working as it should. We should start as anonymous users and see something like this:

We can see that the New Item menu element is gone. That's expected; we're not logged in, so we shouldn't be able to add a new item.

From there, we can click the Login menu element and be brought to the login view, where we can input the admin credentials (admin/pass4admin, in case we forgot). As soon as we hit the Sign In button, we will be routed back to the welcome view, where we should be greeted by something like the following screenshot:

The Login menu element is gone, replaced by Logout and Add New. We can then click on Logout and see both of them replaced by the former again.

So far, so good. However, we're not done with the client yet. These modifications prevent the user from clicking some links they're not allowed to see, yet they are unable to stop the user from going to their given destinations. For example, the user could manually input the routes within the browser's navigation bar and go to the login view while being already logged in, or even worse access the add/edit item view despite being anonymous.

In order to avoid that, we can add a login status check within the login.component.ts constructor (new lines highlighted):

constructor( 
    private fb: FormBuilder, 
    private router: Router, 
    private authService: AuthService) { 
    if (this.authService.isLoggedIn()) {

        this.router.navigate([""]);

    } 
    this.loginForm = fb.group({ 
        username: ["", Validators.required], 
        password: ["", Validators.required] 
    }); 
} 

Also add it to the ngOnInit startup method within the item-detail-edit.component.ts file:

ngOnInit() { 
    if (!this.authService.isLoggedIn()) {

        this.router.navigate([""]);

    } 
    var id = +this.activatedRoute.snapshot.params["id"]; 
    if (id) { 
        this.itemService.get(id).subscribe( 
            item => this.item = item 
        ); 
    } 
    else if (id === 0) { 
        console.log("id is 0: adding a new item..."); 
        this.item = new Item(0, "New Item", null); 
    } 
    else { 
        console.log("Invalid id: routing back to home..."); 
        this.router.navigate([""]); 
    } 
} 

Doing this will also require adding the corresponding import reference line near the topmost section of the item-detail-edit.component.ts file:

import {AuthService} from "./auth.service"; 

And the DI injection in the constructor method:

constructor( 
    private authService: AuthService, 
    private itemService: ItemService, 
    private router: Router, 
    private activatedRoute: ActivatedRoute) { } 

That way, any unauthorized user will be bounced back whenever they try to manually hack our route mechanism by issuing a direct request to these views.

Now that our client is more or less ready, it's time to shield our web API interface from unauthorized requests as well. We can easily do that using the [Authorize] attribute, which can be used to restrict access to any controller and/or controller method we don't want to open to unauthorized access.

To implement the required authorization behavior, it could be wise to use it on the Add, Update, and Delete methods of our ItemsController class (new lines are highlighted):

[HttpPost()] 
[Authorize] 
public IActionResult Add([FromBody]ItemViewModel ivm) 
{ 
    [...] 
} 
 
[HttpPut("{id}")] 
[Authorize] 
public IActionResult Update(int id, [FromBody]ItemViewModel ivm) 
{ 
    [...] 
} 
 
[HttpDelete("{id}")] 
[Authorize] 
public IActionResult Delete(int id) 
{ 
    [...] 
} 

In order to use the [Authorize] attribute, we also need to declare the following namespace reference at the beginning of the file:

using Microsoft.AspNetCore.Authorization; 

Now these methods are protected against unauthorized access, as they will accept only requests coming from logged-in users/clients with a valid JWT token. Those who don't have it will receive a 401 - Unauthorized HTTP error response.

Before closing the ItemsController class file, we should take the chance to remove the item.UserId value override we defined back in Chapter 5, Persisting Changes, when we had no authentication mechanism in place:

// TODO: replace the following with the current user's id when authentication will be available. 
item.UserId = DbContext.Users.Where(u => u.UserName == "Admin").FirstOrDefault().Id; 

Now that we're working with real users, we definitely have to remove this ugly workaround and find a way to retrieve the actual user ID. Luckily enough, when we implemented our very own JWT provider earlier, we did actually put it in the claims JWT token (JwtProvider class, CreateToken method):

new Claim(JwtRegisteredClaimNames.Sub, user.Id), 

This means that we can retrieve it in the following way (updated code is highlighted):

item.UserId = User.FindFirst(ClaimTypes.NameIdentifier).Value;>

Let's perform this change and move on.

Before going further, it's definitely time to perform a client/server interaction test to ensure that our authorization pattern is working as expected.

From the Visual Studio source code editing interface, we can put a breakpoint right below the ItemsControllerAdd method:

Once done, we can hit F5, navigate from the welcome view to the login view, and authenticate ourselves. Right after that, we'll be able to click upon the Add New menu element.

From there, we can fill in the form with some random text and click on the Save button. The form will consequently call the Add method of ItemsController, hopefully triggering our breakpoint.

Open a Watch window (Debug | Windows | Watch | Watch 1) and check the HttpContext.User.Identity.IsAuthenticated property value:

If it's true, it means that we've been successfully authenticated. That shouldn't be surprising, since our request already managed to get inside a method protected by an [Authorize] attribute.