Signup & Next Auth
Hey all! I'm new to sign up and Next Auth and had a question about handling both. I'm using T3 Stack for my app and have a signup form setup and working. I'm wondering when it comes to signin, I query the DB with the user input, if successful should I be using Next Auth Email Provider or Credentials Provider? There are a ton of guides out there for Next Auth but pretty much all of them cover OAuth and not handling email/password signup/login.
I like the MFA provided by Next Auth Email Provider so it'd be nice to keep and and not have to build it from scratch
81 Replies
Because it sucks at email or username auth
What does? That doesn't answer my question
I'm here to learn so I'm open to being taught. I've never dealt with account creating and auth so it's a brand new thing to me. If I should ditch Next Auth that's cool, but why and what else?
next-auth sucks at anything not oauth
Ok I'll look into alternatives. I liked the idea of Next Auth since it would handle sessions and JWT's for me as well as the MFA but if there are better solutions then I'm all for it. Thanks for the feedback
I'm doing credentials with Next Auth right now
it just checks the credentials against a database and returns a JWT to the browser if its a match.
and you get to handle your own verification logic inside the authorize() function in auth/[...nextauth]/route.ts
can you explain in detail what makes it suck at credential based auth? I might jump ship if its bad enough
also what would you reccomend for implementing auth
jwt's, the fact you need to use a jwt because it's credentials is dumb
if you're doing credentials then https://lucia-auth.com/ or rolling auth yourself is what i would do
Lucia
Lucia
whats wrong with jwts for credentials?
what are the downsides to requests getting prefixed by a token unique to that user?
and what would a better alternative be
I kinda just follow OWASP's recommendations, to use sessions whenever you have stateful auth.
The major downside of JWT's is you can't kill a session, or change a role of a person.
Or, it won't be reflected until a new JWT is generated
So if someone is promoted to admin, they won't see until a new JWT is made
If a user is banned off of a service, they're not banned until the JWT runs out
If a user wants to kill a session it can't be
Hm. so if you ban a user, and they keep their old JWT, they can still act as if they weren't banned?
Yup
Since the JWT is either valid or not
Based on encryption
Not based on what the database says
That's the upside, you don't have to access the database to check
By adding a check in the database, but now you've neglected the upside of JWT's
And basically made sessions with JWT's
Doesn't make sense
Just use sessions lol
So with sessions, do you do a db lookup everytime the user does a request?
and verify it against the db?
Yup