Auth0 Home Blog Docs

Dotnet core 2.1, mvc, webapi and angular 6 sample project

angular
mvc
webapi
dotnet-core

#1

Newbie here to Auth0 and OpenId Connect. Briefly, my experience with built-in .net identity or WS-Fed, are the extent of my “security” or IDM experience. I’ve been unlucky to have those pieces in place and mature = no dev experience.

I’m having difficulty migrating from the dbo.AspNetxxxx tables and the built in views that .net provides to manage users and roles, etc. In the past, to customize the AspNetUsers table I implemented my version of IdentityUser and this was easily available after updating the views accordingly.

So the project asks are:

  1. Use an IDM service
  2. The app will be composed of aspnet core MVC, angular 6, and a secured WebAPi.

I’ve found many useful samples in https://github.com/auth0-samples/ but they only address 1 or 2 of the areas I need. Are there any KBs about wrapping everything in the asks. Trying to Frankenstein 3 separate sample projects is a little much.

Sorry, there’s no code but it’s based off this sample: https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/Samples/oauth2.

Pardon, this a very loaded post.


#2

So, compared to what you did in the old days, if you were building a regular web application today that uses Auth0 as the identity provider you would end up with something similar to WS-Federation, except that now you would use the OpenID Connect protocol (OIDC):

  • Session in the web application is, as usual, handled by a session cookie. So after the user authenticates, the application creates a cookie (either stateful or just a reference to a session stored somewhere).
  • Authentication is handled by an external entity (the WS-Federation STS before, Auth0 as OIDC provider) now. When your application detects that the session does not exist, or is expired, it asks the identity provider for an authentication. This is browser based, as with WS-Federation. The interactions with the user are handled by the authentication server domain until control is finally returned to the application.

I would start in the .Net Core 2 Regular Web App Quickstart for a good explanation on this. It uses two middlewares provided by Microsoft in the ASP.Net Core stack:

  • The cookies middleware that:
    • Handles the session cookie.
    • redirects the user to the authentication provider if no session exists and someone tries to access a protected resource
    • Unwraps the cookie sent on every request and prepares the User object (a ClaimsPrincipal instance), accessible from the controller views, with all the information about the user in the form of claims.
  • The OIDC middleware that does all the protocol dance: asks for an authentication when needed, processes and validates the response, and creates the ClaimsPrincipal that will be picked up by the cookies middleware to serialize in the cookie.

Note that, unlike the old .Net identity stuff, this does not attempt to manage users (create, update, delete, passwords) because the expectation is that everything is managed centrally at the identity provider, nor it tries to do role-based access control (roles, permissions, groups).

If you are going to be building a secured WebAPI, you’ll want to look at the Auth0 ASP.NET Core Web API v2.0 SDK Quickstart. This configures the JwtBearer middleware (again, provided by Microsoft) that uses JWT Access Tokens as the mean to authorize requests. The middleware will validate and process the token payload, and will configure the ClaimsPrincipal that, again, will be available in the User property of a controller.
The backend API will be modelled as an “API” in Auth0.

Client applications are expected to request an Access Token from Auth0 to access your backend API.
If you are going to build an Angular application with an ASP.Net Core app as its backend, you can:

We don’t have a sample that has exactly the configuration you are looking for (.Net Core MVC, Angular, .Net Core Web API). Providing all the possible combinations would be impossible, as the benefit of these standard HTTP protocols like OAuth2 and OIDC is that the different pieces can use different technologies. We have the different sections in the https://auth0.com/docs/quickstarts area where you can pick the different pieces.

Hope this helps to clarify the picture a little bit.