There are tons of open source projects to complete the self service experience, from sign up systems to self service password resets
For me the complexity only comes out when things malfunction. However, the MTBF outweighs the MTTR
- 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.
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.
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.
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 :)
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).
[1]: https://developer.okta.com/docs/guides/email-magic-links-ove...
[0] https://github.com/ferg1e/comment-castles
[1] https://www.commentcastles.org/api#api-user-authentication
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?
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.
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.
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.
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).
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.
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 :)
For selfhosting Authentik + Traefik forward auth is a unbeatable combo
This is live at https://screenrun.app/
Just some ip based rate limits.
Ban misbehaved bot ip addresses.
https://hn.garglet.com (advanced search for hacker news)
[1]: https://kanidm.com/
[2]: https://authzed.com/docs/spicedb/getting-started/discovering...
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...
For admin, I use HTTP basic auth like the boomer I strive to be.
Unfortunately many apps tie data to users and need to persist it across devices, which makes some kind of login functionality required.
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:
• Credentials auth
• Google and Microsoft login
• Connected accounts
• Multi-factor authentication (via authenticator app)
• Session management
Very easy and reliable.
