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.