Integrate Hangfire Dashboard with Angular using Azure AD and Azure AD B2C tokens.
This article is simply a further evolutionary step of our applications at Loccioni.
A few months ago, we started using Azure AD and Azure AD B2C authentication for many of our applications. Previously, to authenticate our users, we used local solutions or solutions based on Identity Server 4. Regarding the problem of having to authenticate users to access Hangfire Dashboard, you can refer to my two previous articles: Integrate Hangfire Dashboard with Angular using JWT Token and Hangfire Dashboard and JWT Authentication.
In this episode, we will analyze how to validate a JWT token provided by Azure AD or Azure AD B2C within our authentication filter for Hangfire Dashboard.
I point out that on frontend there is an Angular application that sets a cookie in the iframe with the user’s JWT, in this case, the JWT is the one provided by the Microsoft Authentication Library.
Hangfire Dashboard Authorization Filter
First of all, we need to implement a specific authorization filter to allow Hangfire Dashboard to validate Azure JWT token, this implementation follows the official guide.
The main aspect of this approach is the use of the ConfigurationMananger<OpenIdConnectConfiguration>. Thanks to this manager provided by the Microsoft.IdentityModel.Protocols assembly we can deserialize the OpenId metadata of a tenant.
How to use OpendId metadata in JWT validation?
See OpenID Connect Discovery page to know why it is really useful.
Mainly for two reasons:
- verify that the JWT token has the correct issuer
- verify the signature of the JWT thanks to the public keys that Azure makes available to us (see
config.SigningKeysfrom endpoint https://login.microsoftonline.com/{teanandId}/discovery/v2.0/keys)
Why use IsLastKnownGoodValid?
We want to avoid continuously downloading the OpenId metadata with each JWT token validation request. Thanks to the IsLastKnownGoodValid property, the ConfigurationManager allows us to maintain a cache of the OpenId metadata and its related public keys. See property documentation.
Why did we add an additional issuer on the ValidIssuers list?
I encountered this problem using our Azure AD B2C. As you can see from the issue there are in fact requests for clarification about the correct Issuer found on JWT.
We use v2 of Azure endpoint but we still have JWT generated with https://sts.windows.net/{_tenantId}/ issuer instead the one found on OpenId metadata. We have to investigate more on our side, if you have any advice please let us know!
What about Authorization?
As you can see from the example we have only covered one phase of the problem, authentication.
How can we implement Authorization strategies?
One method is to define a custom claim on Azure AD to identify users who can access Hangfire Dashboard or manage authorization locally in our application.
Stay tuned for the next episode about Hangfire, Angular and Azure integration!
Easy, simple, and maintainable!
Please, Subscribe and Clap! Grazie!
