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:
- Have the Angular front-end talk only to its ASP.Net Core backend (authenticating everything via cookies). The ASP.Net Core backend (like the one mentioned first as the “Regular Web App”) can itself ask for an Access Token (see Auth0 ASP.NET Core MVC SDK Quickstarts: Login), and keep the Access Token secured in the backend as part of the user session.
- Have the Angular application directly ask Auth0 for authentication and an Access Token for the API (this makes the Angular backend rather dumb, only serving the application basic resources like javascript, CSS and HTML). A lone Angular application that requests authentication and access token directly from the front end can be found at Auth0 Angular SDK Quickstarts: Login.
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 Auth0 area where you can pick the different pieces.
Hope this helps to clarify the picture a little bit.