Best Approach For Dynamic Login Screen

[Jubels]

Good Day,

Hope you are well. We at our company are consider using Auth0 for a rewrite on our application. I have done some quite extensive research on the approaches and flows, but would like to get your input.

So our current application is written in .net Framework and razor serving up a server side front-end.
The rewrite would consist out of SPA(vue.js) for Front-end and .net core for backend web api and then sql server as our databases.

With this rewrite we wouldn’t like to change anything on the database side.
So I have read about the web flow which Auth0 provides a login screen which would be used to auspicate user and return an access token would be used a validation for authorized api calls.

The first problem I am encountering is here with login. For each of our clients (different domains pointing to server) we have a custom skin for the login page. So we would definitely want to use our own login screens since it will be dynamic. Unless there is a solution for this.
Other problem I have is that, I want to use our existing user, userRoles and tenant database tables.

So with the research I did, the best solution was this:
Create one client Application on Auth0.
Create one api(Machine-to-machine) on Auth0.
Use our own login screens.
The user would log in with their credentials which would hit a login api on our backend.
The backend would make validate the user against our database. If user is valid we would make a request(Grant type=client_creditials) to get an access token.
The backend’s response to the login would include this access token.
This access token would then be used to make authorized api requests.

So currently this would be our approach. My questions for you is:

1. With context of our application, is still necessary to use Auth0 or should I just use JWT’s
2. Is this approach we are looking at, the best approach for this situation?
3. If there is a better way of handling this could you please provide me with the best approach, keeping in mind the strict restriction for our login screen skins.

Kind Regards
Jeremy

[dan.woda]

Hi @Jubels,

Welcome to the Community.

Thanks for taking the time to detail your plan. Let us see if we can answer some of your questions.

@Jubels

With context of our application, is still necessary to use Auth0 or should I just use JWT’s

In your scenario Auth0 will act as the authorization server. If you do not use Auth0, you will want to ensure you have a bulletproof, tested authorization server to handle issuing tokens. This is a big part of the value of Auth0. Read more:

OAuth 2.0 Authorization Framework

@Jubels

Is this approach we are looking at, the best approach for this situation?

This is not how I would recommend setting up authentication and authorization for your app(s), particularly if you are trying to offload as much of the development to Auth0 and are primarily interested in preserving your custom login pages.

First, you can authenticate directly from your spa, using your custom database as the identity provider (this is an enterprise tier solution), or you can import your db and use auth0 as the idp (this is included in all paid tiers iirc).

Authenticate with Your Own User Store

This will take away the need for a login api. Your users would login directly from a custom login page via your SPA and will return an access token (and optionally an id token) to your SPA to prove the users identity and authorization. These tokens can be sent to your api for requests.

Single-Page Applications (SPA) with API

For the login customization please see this doc:

Centralized Universal Login vs. Embedded Login

Finally, I would encourage you to get a free trial and setup a test app. You can test all the features I mentioned, and see if it is a good solution for you. If everything looks good you would simply have to hook up your DB or migrate your users depending on which route you decide to take.

Let us know your questions.

Thanks,
Dan