Keycloak or auth0. The app should support oauth2, if it does not it gets traefik-forward-auth (or whatever it’s called) to enforce mfa then you are in.
There are tons of open source projects to complete the self service experience, from sign up systems to self service password resets
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 token for a "permanent" token they (the frontend) can use for authentication
- Clicking "Logout" invalidates the currently used "permanent" token
Biggest issue is making sure that whatever email provider you use for the "Login Emails" consistently sends emails quickly, as there is nothing worse but sitting for 2-3 minutes waiting for a login email because the provider batches sends or something.
This would specifically be for side projects. If it grows beyond that, you really should implement something with proper rotation and more, but there are tons of resources about that out there.
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 your auth to derank your standing too. I can force your app to send out bounced emails to hundreds and thousands of bad emails. Costing you $$ or rep in the email exchange. The second affects your ability to authenticate legitimate users too.
Wish magic links would just go away and be acknowledged as an anti-pattern.
> 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 your email provider attempts to scan urls to see where they actually go you end up giving them an auth token
This is what the "change the temporary token for a "permanent" token they (the frontend) can use for authentication" part is for, as it'll require a browser to visit the page so the token can be set in the frontend after making the "switch" with the authentication backend. The tokens get invalidated when used.
Regarding abuse, there is a lot of other things around the design itself that has to be considered that I didn't mention. Rate-limits, validation, verification, operations and other things feel kind of besides the meat of the pattern. Otherwise we'll end up with very long comments :)
> if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token
One way you can handle this is to place the token in the hash portion of the url (which doesn't get sent to servers during an HTTP request), and then have JS on the frontend send the token to your backend manually. As long as the email provider isn't scanning links via a headless browser that executes JS, this should work.
I agree with your point about email abuse though (although you still have to prevent bots from abusing email based password resets).
For some prior art, Okta avoids the email link scanning issue by requiring "same browser, same device" (sessions) [1]. An OTP code is included in the email as a fallback for users receiving mail on a different device than they're trying to log in to.
I develop an internet forum [0] that uses express-session with a Redis datastore for standard username and password website login. Separately, it also has a JSON API that uses OAuth 2 auth code flow with PKCE [1].
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 generous enough to get through the prototype stage.
My main concern is that I don't want to weld too much of my design to any one service provider, so I've got to be careful about taking too much advantage of their feature set and API so that it won't be a pain if they go away or it becomes necessary to migrate to something else.
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 our support team who will verify your account and provide a link from within your Clerk Dashboard to download the complete export directly.
Head of support at Clerk here, can confirm this is accurate. We're right at the finish line with a project that will give you a secure export of your full user data through the dashboard without needing to email support as well.
We are very committed internally to making sure that folks using Clerk are doing so because they want to be, not because we have made it difficult to leave.
Amazon Cognito. If I ever scale past a handful of users and it starts costing money I'll revisit but for a side project? Auth is the least interesting part and I just want it to work securely with no fuss.
In my latest side project I am allowing people to start using the tool without signing up. You can see it working on sandbox.wasitsent.com.
I am using Django’s user system. When a user comes and wants to use the app, I create a Django user and mark it as auto-created. Later, when they decide to sign up, I fill the details and I mark it as auto-created.
Using password auth for now. Will migrate to auth0 if enterprise customers knock on the door and want SAML.
I use Traefik with OpenID Connect for everything, and Google as IdP. It's few enough people that I simply add them manually to traefik-forward-auth's settings in Docker Compose.
Appwrite, all in one, and it shockingly just works from install to go focus on building the side projects.
Cheap/ free to self host. I have tried a bunch of the other ones and they all had things I liked but Appwrite gave me nothing to complain about other than getting on with building :)
Allauth is great. It has so many feature flags for all the microdecisions you want to tune. Social account merges with email account or not... it is configurable! Email confirmation required? Configurable! And it just works.
Generally this. There are obvious reasons you might need to use Oauth2/OIDC... but for side projects, I really don't get why people are so opposed to storing a bcrypt or argon hash, and keeping a session table or using a JWT. I can see "never rolling your own auth" if that meant using your own hand-rolled crypto libraries, but somehow it seems to have became "you must pay for a service or use some magic library".
For admin panels, I use SSH port forwarding, as no additional configuration is needed for that. For users, I use email invite codes that contain the hash of the server’s public key and are pasted into a stand-alone client. That way, I don't need to maintain TLS certificates.
it can be persisted locally and synced to other devices via p2p. It should be doable, similar to screen sharing in etherpad but i have not yet hashed out a complete solution.
Keycloak or auth0. The app should support oauth2, if it does not it gets traefik-forward-auth (or whatever it’s called) to enforce mfa then you are in.
There are tons of open source projects to complete the self service experience, from sign up systems to self service password resets
Is Keycloak really appropriate for a side-project? Seems quite complex AFAICT.
you might be right. I also run freeipa on the backside to manage auth for all of my infra. Maybe I enjoy the flexibility.
For me the complexity only comes out when things malfunction. However, the MTBF outweighs the MTTR
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.
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 token for a "permanent" token they (the frontend) can use for authentication
- Clicking "Logout" invalidates the currently used "permanent" token
Biggest issue is making sure that whatever email provider you use for the "Login Emails" consistently sends emails quickly, as there is nothing worse but sitting for 2-3 minutes waiting for a login email because the provider batches sends or something.
This would specifically be for side projects. If it grows beyond that, you really should implement something with proper rotation and more, but there are tons of resources about that out there.
More commonly known as “magic links” (login).
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 your auth to derank your standing too. I can force your app to send out bounced emails to hundreds and thousands of bad emails. Costing you $$ or rep in the email exchange. The second affects your ability to authenticate legitimate users too.
Wish magic links would just go away and be acknowledged as an anti-pattern.
> 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.
> if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token
This is what the "change the temporary token for a "permanent" token they (the frontend) can use for authentication" part is for, as it'll require a browser to visit the page so the token can be set in the frontend after making the "switch" with the authentication backend. The tokens get invalidated when used.
Regarding abuse, there is a lot of other things around the design itself that has to be considered that I didn't mention. Rate-limits, validation, verification, operations and other things feel kind of besides the meat of the pattern. Otherwise we'll end up with very long comments :)
> if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token
One way you can handle this is to place the token in the hash portion of the url (which doesn't get sent to servers during an HTTP request), and then have JS on the frontend send the token to your backend manually. As long as the email provider isn't scanning links via a headless browser that executes JS, this should work.
I agree with your point about email abuse though (although you still have to prevent bots from abusing email based password resets).
For some prior art, Okta avoids the email link scanning issue by requiring "same browser, same device" (sessions) [1]. An OTP code is included in the email as a fallback for users receiving mail on a different device than they're trying to log in to.
[1]: https://developer.okta.com/docs/guides/email-magic-links-ove...
I develop an internet forum [0] that uses express-session with a Redis datastore for standard username and password website login. Separately, it also has a JSON API that uses OAuth 2 auth code flow with PKCE [1].
[0] https://github.com/ferg1e/comment-castles
[1] https://www.commentcastles.org/api#api-user-authentication
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?
We do now support this, as of late august! https://clerk.com/changelog/2024-08-20-custom-oauth-provider...
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 generous enough to get through the prototype stage.
My main concern is that I don't want to weld too much of my design to any one service provider, so I've got to be careful about taking too much advantage of their feature set and API so that it won't be a pain if they go away or it becomes necessary to migrate to something else.
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 our support team who will verify your account and provide a link from within your Clerk Dashboard to download the complete export directly.
Head of support at Clerk here, can confirm this is accurate. We're right at the finish line with a project that will give you a secure export of your full user data through the dashboard without needing to email support as well.
We are very committed internally to making sure that folks using Clerk are doing so because they want to be, not because we have made it difficult to leave.
Amazing initiative! After hearing this I'm definitely keen to try out Clerk for my next project
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).
What's the use case for the encrypted passwords out of curiosity ?
A lot of my side projects are only visible over a VPN. I have no auth for them as it is not needed.
Ah interesting! I've been experimenting a similar setup.
How do you manage peers and configs?
Manually. It's not that hard.
Amazon Cognito. If I ever scale past a handful of users and it starts costing money I'll revisit but for a side project? Auth is the least interesting part and I just want it to work securely with no fuss.
None, because my projects never make it as far as launching.
haha! The next one will, though! Fingers crossed.
In my latest side project I am allowing people to start using the tool without signing up. You can see it working on sandbox.wasitsent.com.
I am using Django’s user system. When a user comes and wants to use the app, I create a Django user and mark it as auto-created. Later, when they decide to sign up, I fill the details and I mark it as auto-created.
Using password auth for now. Will migrate to auth0 if enterprise customers knock on the door and want SAML.
I first install and configured Authentik with totp then found a million things I can integrate it into because it basically supports everything.
I use Traefik with OpenID Connect for everything, and Google as IdP. It's few enough people that I simply add them manually to traefik-forward-auth's settings in Docker Compose.
https://github.com/thomseddon/traefik-forward-auth
Appwrite, all in one, and it shockingly just works from install to go focus on building the side projects.
Cheap/ free to self host. I have tried a bunch of the other ones and they all had things I liked but Appwrite gave me nothing to complain about other than getting on with building :)
Django allauth, 10 years later still a no-brainer.
For selfhosting Authentik + Traefik forward auth is a unbeatable combo
Allauth is great. It has so many feature flags for all the microdecisions you want to tune. Social account merges with email account or not... it is configurable! Email confirmation required? Configurable! And it just works.
If you’re using allauth why use Authentik vs a database+backups?
I delegate to Puter for https://hackyournews.com
HN post: https://news.ycombinator.com/item?id=41738273
Email+password, jwt tokens. Nothing fancy.
Generally this. There are obvious reasons you might need to use Oauth2/OIDC... but for side projects, I really don't get why people are so opposed to storing a bcrypt or argon hash, and keeping a session table or using a JWT. I can see "never rolling your own auth" if that meant using your own hand-rolled crypto libraries, but somehow it seems to have became "you must pay for a service or use some magic library".
I use firebase auth with Google, Facebook and email (magic link)
This is live at https://screenrun.app/
No login required.
Just some ip based rate limits.
Ban misbehaved bot ip addresses.
https://hn.garglet.com (advanced search for hacker news)
I was thinking Kanidm [1] for authentication and SpciceDB [2] for authorization would be a good combo, but I haven't gotten around to trying it yet.
[1]: https://kanidm.com/
[2]: https://authzed.com/docs/spicedb/getting-started/discovering...
Social auth almost always means oauth (2.0). It's good to have this, because you could technically Deploy your own oauth provider.
However, for my smaller personal side projects I rely on a simple JWT auth based on JWT, QR-codes and https-only AS secure AS possible cookies.
I plan to try openid but i did not habe the time yet.
If you have a userbase, a local username/password login should be at least an Option...
Selfhosted https://goauthentik.io/
For admin panels, I use SSH port forwarding, as no additional configuration is needed for that. For users, I use email invite codes that contain the hash of the server’s public key and are pasted into a stand-alone client. That way, I don't need to maintain TLS certificates.
We use Keycloak
Keycloak OIDC. Cannot go wrong doing this. Enterprise tested, easy to custom style, well documented hosting story, and no lock-in.
Supabase has very easy to setup auth while scaling beyond auth. You can use it standalone without issue.
Phoenix Auth
None or username/pwd
I used to use Facebook because it's really easy to work with
clearly biased: https://corbado.com
Auth0 and FusionAuth
Thanks for the mention. FYI, you can run the community version of FusionAuth for free on fly[0] or render[1].
0: https://fusionauth.io/blog/fusionauth-on-fly-io
1: https://fusionauth.io/blog/fusionauth-on-render
+1 for FusionAuth
X509 certs. They work nicely in an offline situation.
i use lucia in svelte.
https://lucia-auth.com/
Google, Apple, and Email using PocketBase.
Supabase
I make it a point not to have public user accounts for my stuff because it's such a liability.
For admin, I use HTTP basic auth like the boomer I strive to be.
None. Users should handle their own data.
Firebase
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.
I wonder how many apps could get by being front end only (static site) and delegating auth+storage to dropbox (and similar).
Yeah, that's a good question. Did the jamstack folks solve this?
https://www.reddit.com/r/JAMstack_dev/comments/haf3h0/user_a... seems interesting in this context.
it can be persisted locally and synced to other devices via p2p. It should be doable, similar to screen sharing in etherpad but i have not yet hashed out a complete solution.
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 management
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.