JWT validation in Azure Web App
Why
First of all some background of why we are doing this.
In a Sitecore JSS headless project we have an API which is hosted in a Web App. So no Azure Function (we have those as well) but for a number of reasons we choose a WebApi for this part. Some of these api's return sensitive data and need to be secured. And not just secured in a standard way (subscription keys, ...) but also on user level. For some requests you need to be an admin, others can only be requested for yourself and so on.
Also important to mention is that this is a B2B project where the customer decided that the login is done with an Entra App registration in order to provide SSO experience without them having to deal with granting or revoking access - except of course in the custom application itself. As a result, we have no claims in the tokens as at that moment the user is only authenticated but not yet authorized.
As we cannot fetch the role information about a user from the JWT, in our Azure API Management (apim) we can only verify if the token is valid but not the content.
And so, we want to validate the content in the Web App itself. I found a lot of information on the subject, but nothing was really what I needed. But after a lot of trial and error and putting various docs together I finally have something that seems to work.
As Sitecore is becoming more and more headless and distributed and custom api's are probably a part of that it seems like a good idea to share my info.
Goal
To summarize, our goal is to verify if the request came from a specific email - specific can be the same email as in the request data or the email of an admin user. Verification is done based on a JWT that will be created by MS Entra.
Code
Startup
Let's dive straight into it and start with a function that we add in our Program class:
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.AspNetCore.Authorization;
using Microsoft.IdentityModel.Tokens;
void AddPolicies(WebApplicationBuilder builder)
{
var tenant = builder.Configuration.GetValue<string>("TenantId");
var client = builder.Configuration.GetValue<string>("ClientId");
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(opt =>
{
opt.Authority = $"https://login.microsoftonline.com/{tenant}/v2.0"; //.well-known/openid-configuration"
opt.TokenValidationParameters = new TokenValidationParameters
{
ValidateIssuerSigningKey = true,
ValidIssuer = $"https://login.microsoftonline.com/{tenant}/v2.0",
ValidateIssuer = true,
ValidAudience = client,
ValidateAudience = true,
ValidateLifetime = true,
};
});
builder.Services.AddAuthorization(options =>
{
options.AddPolicy("EmailPolicy", policy =>
{
policy.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
policy.Requirements.Add(new EmailRequirement());
});
options.AddPolicy("AdminPolicy", policy =>
{
policy.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
policy.Requirements.Add(new AdminRequirement());
});
});
}
Once we have the authentication in place, we can add the Authorization as that is what we are actually looking for.
For the authorization we can add a Policy. Or in our case two policies as we want to be able to verify the email and the admin status. We will add the code for those policies later.
In the main function we add a call to the AddPolicies and also mention that we want to use Authentication and Authorization.
AddPolicies(builder);
app.UseAuthentication();
app.UseAuthorization();
Policies
Creating the policies is no more than creating an empty class - as example the EmailRequirement:
using Microsoft.AspNetCore.Authorization;
public class EmailRequirement : IAuthorizationRequirement
{
}
Authorization Handler
The next step - and this is where the magic happens - is the authorization handler. You have a few options here as mentioned in the MS-docs article and we decided for one handler to handle all requirements.
using Microsoft.AspNetCore.Authorization;
public class PermissionHandler : IAuthorizationHandler
{
...
public Task HandleAsync(AuthorizationHandlerContext context)
{
if (context.Resource is HttpContext httpContext)
{
var jwtMail = securityService.GetJwtMail(httpContext.Request);
if (string.IsNullOrEmpty(jwtMail))
{
context.Fail();
return Task.CompletedTask;
}
var pendingRequirements = context.PendingRequirements.ToList();
foreach (var requirement in pendingRequirements)
{
if (requirement is EmailRequirement)
{
var email = GetEmail(httpContext.Request);
if (!string.IsNullOrEmpty(email) && ...)
{
context.Succeed(requirement);
}
else
{
context.Fail();
}
}
else if (requirement is AdminRequirement)
{
...
}
}
}
return Task.CompletedTask;
}
private static string? GetEmail(HttpRequest request)
{
...
}
}A PermissionHandler is a straight forward class that checks the requirements sets the context to success or failure and return the task completion. In our case we are first getting the email address from the JWT (details follow) and if we have an email we loop over the requirements.
Those are pure business logic. As an example for the EmailRequirement we fetch the email from the request (how to do this is dependent on how that information is being send to your api's). If the email is valid (equal to the one in the JWT) we set the context to be succeeded - otherwise it failed.
We repeat this for every requirement needed.
Getting the email from the JWT
using System.IdentityModel.Tokens.Jwt;
public class SecurityService : ISecurityService
{
...
internal static string? GetJwt(HttpRequest request)
{
try
{
var jwt = request.Headers.Authorization;
if (jwt.Count == 1)
{
var jwtSplit = jwt.ToString().Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);
return jwtSplit.Last();
}
}
catch
{
return null;
}
return null;
}
public string? GetJwtMail(HttpRequest request)
{
try
{
var jwt = GetJwt(request);
var handler = new JwtSecurityTokenHandler();
var token = handler.ReadJwtToken(jwt);
var claim = token.Claims.FirstOrDefault(c => c.Type.Equals("email", StringComparison.OrdinalIgnoreCase));
if (claim != null)
{
return claim.Value;
}
}
catch
{
return null;
}
return null;
}
}
The JW token is in the Authorization header. We split that string as we don't want the "Bearer" part that precedes the token. We parse the token and get the email from the claims.
Don't forget to register Permissionhandler in your main class:
builder.Services.AddScoped<IAuthorizationHandler, PermissionHandler>();That wraps up all the code that we need to write. Now we can start using the Authorization attribute on our api's. On all task in your controller you can add the attribute with the name of the requirement that is needed:
[Authorize(Policy = "EmailPolicy")]And that's all folks.
I had to get quite a few blogpost and documentation pages together to get this working and I learned that any change in the architecture or setup change the way you should do this, so I hope this explanation will be useful to someone. And if not completely what you need, it might get you in the right direction.
