Live data from Hacker News

Ask HN: What type of Auth are you using on your side projects?

news.ycombinator.com

51–60 of 72 posts

Re: Ask HN: What type of Auth are you using on your side projects?

#51
post #12

Auth.js! Supported providers: https://authjs.dev/getting-started/providers/github It's been really great so far and I can recommend it if you have a JS/TS codebase. ---------------------------- You can test Auth.js (v5 beta.22) in my Next.js 15 boilerplate: https://achromatic.dev • Credentials auth • Google and Microsoft login • Connected accounts • Multi-factor authentication (via authenticator app) • Session manage…

That's what I'm using too. Along with a very easy integration with Resend for magic link email.

+ 1 for React Email and Resend.

Very easy and reliable.

Re: Ask HN: What type of Auth are you using on your side projects?

#52

Earlier quoted context omitted.

Keycloak has too many new major releases. It is a real pain to keep up with.

Their version numbers are meaningless in that way. Most major up upgrades are non events

They can, and do, introduce breaking changes in major releases. That is the issue.

Re: Ask HN: What type of Auth are you using on your side projects?

#55
post #48

no auth at all

Haha, that's the best way to do it if you can swing it. It's like writing no code.

Unfortunately many apps tie data to users and need to persist it across devices, which makes some kind of login functionality required.

Re: Ask HN: What type of Auth are you using on your side projects?

#56
post #20

This is the absolutely simplest of authentication (not authorization) schemes I've used that is both easy for people to use and prevents the simplest of spam/robots: - Be able to store two types of tokens, one that is temporary, and one that is "permanent" - Users can use their email address to get sent a temporary token (which expires if unused after X minutes) - Users can click that link to change the temporary tok…

I personally just really don't like magic links auth. It just feels brittle and if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token and by the time the user clicks the link it's invalidated (or you don't invalidate the link at all which is worse). If you have an issue with bots on your platform you're going to always have bot problems. It's trivial to abuse…

> It just feels brittle and if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token and by the time the user clicks the link it's invalidated (or you don't invalidate the link at all which is worse).

At my current employer (an auth vendor) we ended up changing our magic link behavior to require a post from the user to log in because of this issue (the scanners didn't get an auth token, but they did invalidate the one-time code and confuse end users to no end.

If you want more details, there is some discussion here: https://github.com/FusionAuth/fusionauth-issues/issues/2443 and on the related issues.

Re: Ask HN: What type of Auth are you using on your side projects?

#57
post #40

I’ve been using https://clerk.com . Not needing to build authentication / the UI / … as well as not worrying about hosting it myself has been nice.

I know the clerk folks a bit. They have a nice generous free tier ( https://clerk.com/pricing ).

I believe they don't fully support OAuth/OIDC, which may or may not be a problem based on what you are trying to solve.

Any particular strengths or challenges of their approach that you've found?

Re: Ask HN: What type of Auth are you using on your side projects?

#58
post #14

I've been in big tech and out of touch with the real world for a while, and I started a project only a couple of weeks ago to get a feel for what the cool kids are doing in web dev in 2024. So I can't claim any deep authority or experience with a lot of different approaches. But I picked Clerk because it was in a tutorial, and so far so good. It couldn't have been much easier, and the free tier seems more than genero…

Lock in is definitely a valid concern, I emailed customer support and they replied with this: Certainly understandable to worry about lock-in! We do try and make data exports as easy as possible. You can use our Backend API directly to retrieve all data for your users except for passwords: https://clerk.com/docs/reference/backend-api/tag/Users#opera... If you need encrypted passwords in the export, you can contact ou…

This is great! I have looked at a lot of the vendors for my day job and it seems most everyone gives out password hashes.

The two most popular ones that don't (just to name and shame):

Amazon Cognito

Microsoft Entra ID (used to be Azure AD)

They really should (though gating behind support makes sense--hashes are sensitive).

Post reply on HN