As I don't have personal or professional use for it any longer, and I'm lacking time and motivation to maintain a package I dont need, this repository has been archived with November 16th, 2024. There won't be any new releases, security patches or whatsoever. I decided to archive and keep it as readonly repository, because I think it's a neat showcases of how the process of building an authentication ticket in ASP.NET Core can be augmented by utilizing existing hooks. Maybe someone can identify patterns to solve a problem s/he's facing right now.
If somebody did ever use this package: I hope it saved you some hours of development. Cheers.
AuthOida closes a gap in Microsoft.Identity.Web, where Azure Active Directory group
assignments for an identity are only appended to the token using the groups ObjectID instead of
their display name. Refer to StackOverflow
and a GitHub issue for some details.
AuthOida supports WebApps and API scenarios likewise, as long as Microsoft.Identity.Web is
used for authentication. For both use cases AuthOida provides an extension method
AddMappedGroups() as primary hook.
Important: AuthOida makes use of Microsoft Graph to query the groups display names after the the JWT/OIDC token has been validated. Therefore the respective App registration needs to configure Group.Read.All Application permissions for the Microsoft Graph API, so that the application can read group details. Please note, that Delegated permissions are not yet supported, and that there are not plans for it to be implemented.
Since the application itself also acts as a confidential application when querying the Graph API, you
need to either specify a ClientSecret or provide at least one ClientCertificate within the
MicrosoftIdentityOptions configuration. AuthOida will reuse it to authenticate with Microsoft
Graph. (Please note, that if both are specified, AuthOida will authenticate using ClientCertificate in favor of
ClientSecret.)
Kindly refer to samples/AuthOida.Sample.App for a runnable sample of a WebApp using AuthOida.
services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"))
.AddMappedGroups();Kindly refer to samples/AuthOida.Sample.API for a runnable sample of an API using AuthOida.
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApi(Configuration.GetSection("AzureAd"))
.AddMappedGroups();AuthOida makes at least one API call to MS Graph querying all groups of an AD instance for their display names during the lifetime of an application instance. Therefore the first request to a new instance could potentially experience a significant response delay. I only tested it with an AD instance containing a rather small number of groups, so any experience with bigger AD instances would be highly appreciated.
Consider prewarming instances, so that subsequent requests will fallback to the cache, if you experience significant delays on the first request.
AuthOida builds up a lookup dictionary, that is bound to the application lifetime. As long as the application is loaded, AuthOida will reuse the previously queried lookup pairs.
Note: AuthOida does not attempt to refresh this cache, as groups display names are considered to be rather static.
AuthOida is not thread safe in that sense, that for n simultaneously arriving first requests there
could be a race, where the application groups would be queried n times instead of only once.
This does not cause any harm, as the caches would simply be replaced with one another.
Active Directory groups, that are synced from an on-premise instance most likely do not suffer from the issue described above. As of now, the groups display names are only omitted for Azure AD security group instances.