ASP.NET Core is a fantastic framework for web applications, representing a
significant leap in architecture design compared to ASP.NET MVC. However, as I
began working with it, I noticed it has strong opinions about how certain
things should be done. These preferences are evident not just in the framework
itself but also in various tutorials and blog posts created around it.
If you prefer doing things in your own way, finding assistance can be
challenging. One common preference is using the Authorization header token
authentication, like JWT, for Single Page Applications (SPA). Personally, I
struggled to find tutorials or documentation explaining how to use cookie
authentication for SPAs in ASP.NET Core.
I won't get into the ongoing debate about whether this idea is good or not, as
there are plenty of blog posts and videos discussing it already. In this
article, I will show you how I managed to set up cookie authentication in a
Single Page Application (SPA) using the ASP.NET Core SPA template. Along the
way, I'll share the challenges I faced and the things you need to be cautious
about. It's also a chance to dig a bit deeper and understand some internal
aspects of the framework.
The Design:
When I began software development, authentication and authorization were
always significant points of discussion. The key takeaway is that there isn't
a universal solution that fits all scenarios. The strategy chosen depends
heavily on the specific requirements of the application in question.
The design I'm explaining in this article is specific to this particular
application. It's important to note that it might not be the best or a perfect
solution for every situation.
There are two main approaches here. One is to start from scratch, creating
your own middlewares and filters and writing all the code yourself. The other
approach is to make the most of what the framework provides, customizing only
the necessary parts. I'm opting for the latter method.
The idea is straightforward: once the user logs in, I generate a JWT token and
send it as an "Http Only" cookie. This method ensures that XSS scripts can't
capture the token.
private readonly LoinUserService _loginUserService;
private readonly IAntiforgery _antiforgery;
public UserApiController(LoinUserService loginUserService,
IAntiforgery antiforgery)
{
_loginUserService = loginUserService;
_antiforgery = antiforgery;
}
private void RefreshedCSRFToken()
{
var tokens = _antiforgery.GetAndStoreTokens(HttpContext);
HttpContext.Response.Cookies.Append("XSRF-TOKEN",
tokens.RequestToken,
new CookieOptions() { HttpOnly = false });
}
[HttpPost]
[Route("login")]
[ValidateAntiForgeryToken]
[ValidateModel]
[TrimInputStrings]
public async Task<IActionResult> Login([FromBody]LoginModel loginModel)
{
var userDto = await _loginUserService.LoginAsync(loginModel);
if (userDto == null)
{
return Unauthorized("Invalid user name or password.");
}
var claimsIdentity = _loginUserService.GenerateClaimsIdentity(userDto);
var jwtToken = _loginUserService.GenerateJwtToken(claimsIdentity);
HttpContext.User = new ClaimsPrincipal(claimsIdentity);
RefreshedCSRFToken();
HttpContext.Response.Cookies.Append("jwt",
jwtToken,
new CookieOptions() { HttpOnly = true });
return Ok();
}
I won't explain how to create the claims and generate the JWT cookie here
because there are many online tutorials covering that. The key point is that
the JWT is sent back as an "Http Only" cookie and isn't directly controlled by
the client application.
We opt for cookie authentication instead of the usual JWT authentication for
our authentication scheme.
public void ConfigureServices(IServiceCollection services)
{
services.Configure<CookiePolicyOptions>(options =>
{
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
services.AddAntiforgery(options => {
options.HeaderName = "X-XSRF-TOKEN";
options.Cookie = new CookieBuilder()
{
Name = "XSRF"
};
});
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie();
}
Here's where ASP.NET Core steps in with its perspective. I couldn't find a
pre-built solution to decode the JWT stored in a cookie; the available ones
decoded it only from the header. So, I developed a custom middleware. Its sole
job is to verify if the JWT is still valid. If it is, the middleware populates
the HttpContext User (ClaimsPrincipal) with the data from the JWT.
public static class JwtCookieAuthMiddleware
{
public static void UseJwtCookieAuthMiddleware(this IApplicationBuilder app,
IAntiforgery antiforgery,
byte[] key,
bool autoRefresh = true,
string cookieName = "jwt",
string csrfCookieName = "XSRF-TOKEN")
{
app.Use(async (context, next) =>
{
string jwtStr = context.Request.Cookies[cookieName];
if (string.IsNullOrEmpty(jwtStr))
{
await next();
return;
}
var validationParameters = new TokenValidationParameters
{
// Clock skew compensates for server time drift.
ClockSkew = TimeSpan.FromMinutes(5),
ValidateIssuerSigningKey = true,
IssuerSigningKey = new SymmetricSecurityKey(key),
RequireSignedTokens = true,
RequireExpirationTime = true,
ValidateLifetime = true,
// Ensure the token audience matches our audience value (default true):
ValidateAudience = false,
ValidateIssuer = false
};
ClaimsIdentity claimsIdentity = null;
ClaimsPrincipal newPrincipal;
JwtSecurityToken jwtToken = null;
try
{
var claimsPrincipal = new JwtSecurityTokenHandler()
.ValidateToken(jwtStr,
validationParameters,
out var rawValidatedToken);
//rawValidatedToken.
claimsIdentity = new ClaimsIdentity("AuthenticationTypes.Federation");
foreach (var claim in claimsPrincipal.Claims)
{
if (claim.Type == "iat" ||
claim.Type == "exp" ||
claim.Type == "nbf")
{
continue;
}
claimsIdentity.AddClaim(claim);
}
newPrincipal = new ClaimsPrincipal(claimsIdentity);
context.User = newPrincipal;
jwtToken = rawValidatedToken as JwtSecurityToken;
context.Items[Constants.JwtTokenKey] = jwtToken;
}
catch (Exception)
{
var tokens = antiforgery.GetAndStoreTokens(context);
context.Response.Cookies.Append(csrfCookieName,
tokens.RequestToken,
new CookieOptions() { HttpOnly = false });
context.Response.Cookies.Delete(cookieName);
}
if (autoRefresh &&
jwtToken != null &&
claimsIdentity != null)
{
CheckAndRefreshToken(key, claimsIdentity, jwtToken, cookieName, context);
}
await next();
});
}
}
CSRF Protection:
As expected with this cookie-based authentication, it comes with a Cross Site
Request Forgery (CSRF) threat. Here's where another challenge arises in the
ASP.NET Core framework. CSRF protection involves two components: a "Http Only"
cookie containing the CSRF token that remains active for the session and a
request token that must accompany the request, either in the form body or as a
header. In traditional MVC applications, placing the token as a hidden field
in the form is straightforward. However, in Single Page Applications (SPAs),
POST requests are usually sent in JSON format. This means the CSRF request
token must be included in the request header, adding a layer of complexity.
Here's the tricky part: the CSRF request token is computed based on both the
CSRF cookie and the claims in the HttpContext User ClaimsPrincipal. If any
claim differs for the CSRF request token, it won't function properly. That's
why we remove certain claims like "iat," "exp," and "nbf" when setting up the
ClaimsPrincipal. By doing this, if we refresh the token (which isn't discussed
in this article), we don't need to regenerate the CSRF request token. This
prevents it from failing in the current request.
In a Single Page Application (SPA), every time a user logs in, a new request
token needs to be sent to the client through a cookie that isn't "Http Only".
This allows the client to access it and place it in the header. When the user
logs out, the CSRF request meant for the anonymous user also needs to be sent
back to the client. You can observe this process in the logout section
provided below.
In the middleware code, when the JWT token expires, we send a CSRF request
token for the anonymous user, similar to the logout action. This allows the
client to continue working with the login endpoint and other functionalities.
[HttpGet]
[Route("logout")]
public IActionResult Logout()
{
HttpContext.User = new ClaimsPrincipal();
RefreshedCSRFToken();
HttpContext.Response.Cookies.Delete("jwt");
return Ok();
}
CSRF for unsecure actions:
Everything is running smoothly, but there's one scenario where this approach
might lead to an unexpected error. If a user is authenticated and makes a POST
request for an action that doesn't need authentication, and the token has
expired, the request will fail. This happens because the token sent is for a
specific user (with certain claims), but now the anonymous user is in the
ClaimsPrincipal. It's important to note that since the middleware updates the
cookie when the JWT token expires, the next request will work as expected.
Is this the only solution to this problem? Not at all, there are alternatives.
One option is to not enforce CSRF protection for this particular endpoint. In
your application's design, any action considered insecure should not involve
user authentication or make changes requiring it. By ensuring this, there's no
benefit for anyone trying to deceive your user with a malicious CSRF page,
because they can't perform any actions that require authentication.
A major question arises: should CSRF be used for actions that don't require
authentication? Take the login page, for example. It doesn't necessarily need
CSRF protection since the user isn't authenticated at that point.
In my method, I do include CSRF protection even for insecure actions, just to
ensure extra security, especially on the login page. To have the CSRF token
available when the user loads your SPA, you also need a middleware to send
this request token. This process is demonstrated in the example below.
public static class AntiforgeryCookieTokenMiddleware
{
public static void UseAntiforgeryCookieTokenMiddleware(this IApplicationBuilder app,
IAntiforgery antiforgery,
string cookieName = "XSRF-TOKEN")
{
app.Use(async (context, next) =>
{
var tokens = antiforgery.GetAndStoreTokens(context);
context.Response.Cookies.Append(cookieName,
tokens.RequestToken,
new CookieOptions() { HttpOnly = false });
await next();
});
}
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseSpaStaticFiles();
app.UseCookiePolicy();
app.UseJwtCookieAuthMiddleware(app.ApplicationServices.GetService<IAntiforgery>(), Encoding.ASCII.GetBytes("signing key"));
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
app.UseAntiforgeryCookieTokenMiddleware(app.ApplicationServices.GetService<IAntiforgery>());
app.UseSpa(spa =>
{
spa.Options.SourcePath = "ClientApp";
if (env.IsDevelopment())
{
//spa.UseReactDevelopmentServer(npmScript: "start");
spa.UseProxyToSpaDevelopmentServer("http://localhost:3000");
}
});
}
This middleware should be placed right before the app.UseSpa() middleware.
Here's why: when the request goes through the previous middlewares and doesn't
match any file or action, the UseSpa middleware sends your Index.html
containing the SPA code to the user. As for the JWT Cookie middleware, use it
in the same way you would use the default authentication middleware in ASP.NET
Core.
Comments
Post a Comment