The .NET ecosystem has become quite complex. On the one hand, developers can create different types of applications for different platforms. On the other hand, in its 20-year history, .NET has generated different versions of the development platform, some incompatible with each other or compatible under specific criteria.
Auth0 provides developers with a few SDKs for different application types and different versions of the platform. Which one is right for your application? Let's find out together!
If you want to find out directly what is the SDK or package to use in your .NET application to integrate with Auth0 without sitting through the rationale behind it, jump to the section The Matrix of Solutions.
The Dimensions of the Problem
Let's start by exploring the dimensions of the problem, that is, the factors that influence the choice: the application type, the .NET target, and the role of Auth0.
The application type
As the first dimension, you need to consider your application type. As a .NET developer, you know that the development platform allows you to create applications of several types: from Web to desktop apps, from Web APIs to mobile apps. You can also use different frameworks to build your app. For example, you leverage ASP.NET or ASP.NET Core to build a Web application, but you can use ASP.NET Core MVC or Razor Pages or Blazor Server as the frameworks that support your UI and application architecture. Something similar happens for desktop app UIs: you can use WinForms or Windows Presentation Foundation (WPF) or Universal Windows Platform (UWP), etc.
Identifying your application type and the technology you use or you are going to use is the first step to determining which SDK you must use.
The .NET target
The second dimension is the .NET version your application runs on, which in the .NET lingo is called your application's target. The .NET platform has evolved over the past two decades and has undergone several transformations. From the initial multi-language framework for Windows programming, it has now become a cross-platform development environment that enables the creation of Web, desktop, and mobile applications. You can take into account the following targets:
- .NET Framework. This was the initial Windows framework, which will be deprecated, but on which many applications still run.
- .NET Core. The initial cross-platform version of .NET, which is not fully compatible with the .NET Framework. The last .NET Core version was 3.1.
- .NET Standard. Actually, this is not a true .NET version. It is a specification that aims at defining a common set of APIs between .NET Framework and .NET Core to ensure a degree of compatibility between the two versions. Auth0 SDKs follow .NET Standard 2.0 specifications to keep this compatibility.
- .NET. This is the current and universal version of the development platform that aims to replace all the previous ones. From the Auth0 point of view, it can be seen as the evolution of .NET Core.
To learn more about the differences between the .NET targets, check out this article.
The role of Auth0
The third dimension is the purpose of using the Auth0 platform in your application. Your application can use Auth0 for three main reasons:
- To add authentication so that your users can log in using the Auth0 Universal Login page, Single Sign-On (SSO), Passwordless, Social Login, and the other approaches available with Auth0.
- To control access so that only authorized users can use your application's functionality.
- To manage users and other features provided by your Auth0 tenant.
Clarifying the purpose of Auth0 in your application is also important to determine which SDK you must use.
The Auth0 SDKs and Packages
After analyzing the dimensions of the problem, let's see what Auth0 offers to meet the needs of .NET developers. You can use a few SDKs to integrate Auth0's authentication, authorization, and management features into your .NET applications. Each SDK includes one or more packages that you can install from NuGet.
Let's take a look at these SDKs and their packages.
Auth0 ASP.NET Core Authentication SDK
The Auth0 SDK for ASP.NET Core Authentication is designed for adding authentication support to your Web application built with server-side frameworks: ASP.NET Core MVC, Blazor Server, and Razor Pages. It provides you with one package — Auth0.AspNetCore.Authentication, which hides most of the complexity of the authentication and authorization process.
Check out this article for a quick introduction to the Auth0 ASP.NET Core Authentication SDK's main features.
Auth0 OIDC Client for .NET
The Auth0 OIDC Client for .NET supports OpenID Connect-based authentication in your .NET desktop application as well as in your mobile application based on Xamarin. The SDK provides multiple packages depending on the framework used for your application's UI:
- Auth0.OidcClient.UWP. This package supports Universal Windows Platform (UWP). Check out this document to learn how to use it.
- Auth0.OidcClient.WPF. This package supports authentication for desktop apps using Windows Presentation Foundation (WPF). Take a look at this document to learn how to use this package.
- Auth0.OidcClient.WinForms. With this package, you can add authentication to your WinForms-based desktop application. This document will guide you on how to use it.
- Auth0.OidcClient.Android. This package adds authentication to Xamarin-based mobile apps for Android. Read this document to learn how to start.
- Auth0.OidcClient.iOS. This package adds authentication to Xamarin-based mobile apps for iOS. Check out this document to learn how to use it.
Auth0 .NET SDK
The Auth0 .NET SDK enables your .NET Framework and .NET Standard application to authenticate users and manage your Auth0 tenant. It implements two packages:
- Auth0.AuthenticationApi. This package is a wrapper around the Auth0 Authentication API, which allows you to add login, logout, signup, and other functionality to your application. This is not a high-level authentication library, since you need to handle the steps of the authentication and authorization process. It assists you in building authorization URLs through a few URL Builders, but it's up to you to run validation. Check out this document for an introduction to how to use the Auth0.AuthenticationApi package.
- Auth0.ManagementApi. This package allows you to interact with your Auth0 tenant programmatically. It is a wrapper around the Auth0 Management API and basically allows you to do with your .NET application what you can do with your Auth0 dashboard: you can manage users and roles, create and get application settings, manage your Auth0 Actions, control your branding, and so on. Check out this document for a quick introduction to how to use the Auth0.ManagementApi package.
Leverage Auth0's authentication and authorization services in your .NET applications.
DOWNLOAD THE FREE EBOOKThe Matrix of Solutions
Now that you've reviewed the dimensions of the problem and the available Auth0 packages let's create a map that allows you to find on the fly which package to use for a given application type. In the following, you will see three sections, one for each Auth0 role in your application. Within each section, you will find a matrix that matches the application type with the .NET target and proposes the appropriate package. Note that a specific SDK may not be available for some combinations because native .NET support is sufficient or because there are viable third-party alternatives.
Authentication
If your application uses Auth0 to add authentication support, check out this matrix to choose the right package:
.NET Framework | .NET (Core) | |
---|---|---|
ASP.NET MVC | Microsoft.Owin.Security.OpenIdConnect | |
ASP.NET Core MVC | Auth0.AspNetCore.Authentication | |
Razor Pages | Auth0.AspNetCore.Authentication | |
Blazor Server | Auth0.AspNetCore.Authentication | |
Blazor WebAssembly | Microsoft.AspNetCore.Components.WebAssembly.Authentication | |
Xamarin | Auth0.OidcClient.Android Auth0.OidcClient.iOS | Auth0.OidcClient.Android Auth0.OidcClient.iOS |
WPF | Auth0.OidcClient.WPF | |
WinForms | Auth0.OidcClient.WinForms | |
UWP | Auth0.OidcClient.UWP | |
MAUI | IdentityModel.OidcClient | |
Console | Auth0.AuthenticationApi | Auth0.AuthenticationApi |
Notice that for ASP.NET MVC we suggest using Microsoft's standard OWIN library. For .NET MAUI applications, you can use the well-known OpenID Connect Client Library for Native Applications. Check out this article to learn how to use this library to add authentication to .NET MAUI apps.
Access control
If your application uses Auth0 to check access control to server resources, that is, you are implementing a Web API, check out this matrix to choose the right package:
.NET Framework | .NET (Core) | |
---|---|---|
ASP.NET Web API | Microsoft.Owin.Security.Jwt | |
ASP.NET Core Web API | Microsoft.AspNetCore.Authentication.JwtBearer |
As you can see, you can use Microsoft's standard libraries to check JWT tokens in Web APIs.
Auth0 tenant management
If your application needs to manage users and other Auth0 tenant features, refer to this table:
.NET Framework | .NET (Core) | |
---|---|---|
Any app type | Auth0.ManagementApi | Auth0.ManagementApi |
The Auth0 Management API can be used for any application type targeting any .NET version.
Try out Auth0 authentication for free.
Get started →Summary
Throughout this article, you learned the criteria you must follow to determine the appropriate SDK and package for your .NET application. The current platform complexity is reflected in the complexity of choosing the right package, of course. With the .NET platform unification, general simplification is expected in the near future, but we cannot forget the legacy code that is still up and running.
So, for your next .NET project, go and pick the right Auth0 SDK!
About the author
Andrea Chiarelli
Principal Developer Advocate
I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.
In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.