I’m pretty new to Auth0 but not new to web development or auth mechanisms - I wanted to ask a couple of quick questions to figure out if Auth0 is a good fit in my architecture, I’ve read over a lot of documentation on different approaches and I’m a bit burned out.
I’ve got three components right now:
A Node/Express/Mongo based API server
Two NextJS applications that communicate with said API server.
My plan is to support basic user/password based auth and write to a MongoDB rather than keeping details on the Auth0 side
I’d like to expose ‘create’, ‘login’, ‘logout’ & ‘reset’ endpoints on my API server so my NextJS apps can create & auth users using my API server as a gateway to Auth0. Then I’d like my API server to return JWT tokens back to the client to store as a cookie, both so I can auth with my API server but also so I can render secured routes in my NextJS apps.
Alternatively, I’d still like to be able to sign up via my API, but I’d be happy using the Universal flow and redirecting to .auth0.com to login, however I’m a little fuzzy on if I could use this method to authenticate both my Next apps and any requests from my Next apps to my Node API
My questions are;
Is Auth0 a good fit here or is it overkill? I’ll only be using email/password auth but I’d like to avoid having to implement my own password reset flows/avoid my API server sending emails
Is is possible to programatically create users from a Node app via Auth0? To clarify, I’d be passing a bunch of details from my Next app to my API server, then to an Auth0 API endpoint.
If using the Universal login, can I get JWTs that I can then use from my Next apps to my Node API to authenticate API requests?
If I can use the Universal login, can my Node API server validate/decode the JWTs from my Next apps for authorisation/authentication if they’re sent in the API request headers?
Is it a sensible idea to use JWTs for this usecase? I read a quickstart guide for node that used passport but it stored sessions statefully which is something I want to avoid
What should my configuration look like on the Auth0 side - would I need to create three applications (1 Node & 2 Next) or just one application for the Node API server? If the latter, should this be a Machine-to-machine type or another type?
If you goal is to simplify your auth related processes (email verification, pw reset, RBAC etc.) then I would say it is worth it.
Auth0 can also manage issuing tokens, which needs to be bulletproof if you chose implement that on your own. Email/PW is a standard feature, and fairly straightforward to setup. I would recommend doing this if you are setting up with Auth0.
Is there a reason why you want your server to handle signup, login, logout? Typically you delegate this to auth0 and then store the user id in your db for reference whenever you receive a token. This is a more common setup.
This is possible via the management API and via the /signup endpoint of the authentication API.
Yes, please look at this architecture scenario for an example:
Yes! Take a look at the node quickstart doing just that:
Yes.
You should create two next apps and one api. You can manage scopes and users in the dashboard. Take a look at the architecture scenario I linked above.
Take a look at this topic and article (if you haven’t already stumbled upon it).
I would recommend letting Auth0 handle user login and creation, as that is something we do well. Especially if you like the look and feel of universal login. I would say get a trial account and setup your apps and api. It is fairly straightforward to getting a demo working with the quickstarts.
Hey @dan.woda, thanks for getting back to me so quick!
Those resources are great! Auth0 has tons of great documentation, it can be a little overwhelming, so its really useful to have a couple of articles cherrypicked by an expert
I’ve already wired up a signup flow in one of my Next apps and right now its posting to my API to create a user account, so I’d like to retain as much of that as I can by wiring Auth0 into my API endpoint rather than having to redirect to Auth0 on the client side partway though my signup flow. Is that possible to do programmatically with the /signup endpoint of the authentication API?
The ideal is for my client to post the signup data to my API, the API sends off a ‘create user’ call to Auth0, and Auth0 writes the user details to my MongoDB instance - is that possible/reasonable with Auth0?
I’m a lot less precious about the login/logout endpoints, I’d be happy using the universal login for that so what should simplify things
Just to keep you in the loop, I’ve set up a MongoDB connection to write my users to my database & I’ve configured my Node API to check token validity & to create users via the management API - all’s looking great on that side!
I had a question about persisting passwords - I obviously don’t want to store passwords in plaintext in my database so I was planning on salting/hashing them before sending them over to Auth0. Would it make sense for me to hash/salt the password in my Node API before sending it over to Auth0 to write or is there a better way to do this?
If I can do this, I’m guessing I’ll have to implement the same salting/hashing in my ‘Login’ database access script so that Auth0 will be able to verify the password, and in my ‘Change Password’ database access script?
Absolutely! This is what the signup endpoint is intended for. It is a great middle ground, letting you customize all the necessary signup and registration data/UI, but still delegating authentication to Auth0.
Your front end sends a request to your api with the user data
Your API makes a request to the /signup endpoint with the user data (you could actually skip this step and make the signup request directly from the frontend).
Read through this doc for examples and more info/limitations:
I am a little bit confused on this part. Are you using your mongo database for authentication? If so, that would require a custom db connection. This is possible, but will require an enterprise tier account.
Otherwise you should use the /signup endpoint which will not require you to handle any passwords or hashes outside of the initial signup request, which is the same as sending form data to your API, you instead just send it to the authentication API.