Future plans #1707
Replies: 42 comments 83 replies
-
|
What do you mean doesnt work? |
Beta Was this translation helpful? Give feedback.
-
|
Second this! curious for this point to be expanded on a bit more. Admittedly I found the learning curve a bit steeper in Lucia compared to other libs like Auth.js but I've grown to really enjoy using it, so sad to see this project end. What I love is how explicit everything is, which does it make more verbose, but the trade for more control feels well worth it. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, forgot to reply to this. I think the general idea of database adapters to be a flawed model, especially when you need to customizability. Didn't help that Lucia doesn't do much except for some date time operations. |
Beta Was this translation helpful? Give feedback.
-
|
It's indeed felt that it's hard for library to keep up with ORM changes. Lucia's guide and explanation of how auth is done has always been outstanding, and I’m looking forward to see it's becoming even better. Thank you for the work you've done. |
Beta Was this translation helpful? Give feedback.
-
|
I think the issue is in the "trying to cover every use case", people who need complex solutions should roll their own auth from the bottom up. For people who only want more-or-less to be able to support a couple of oAuth providers, have a Nonetheless, thanks for all the work you have put into the library and resources @pilcrowonpaper. |
Beta Was this translation helpful? Give feedback.
-
|
exactly. Whole startups were built around that, but Lucia is cool cuz it's simple, and yeah for sure it makes you understand how things work. |
Beta Was this translation helpful? Give feedback.
-
|
I am looking forward to Lucia being a good resource for learning auth. Basically everyone has different specific needs as soon as you start doing something just a bit complex. That's the thing, auth is a concept and design pattern, not a library or framework. Your only bet is to learn to do it well. |
Beta Was this translation helpful? Give feedback.
-
|
I just planned to use lucia for the first time but I guess nope |
Beta Was this translation helpful? Give feedback.
-
|
same... |
Beta Was this translation helpful? Give feedback.
-
|
You can still use it.. and then migrate. Shouldnt take more than 1 hour |
Beta Was this translation helpful? Give feedback.
-
Migrate to what? I'm open to recommendations. I needed it for a project i was about to start |
Beta Was this translation helpful? Give feedback.
-
|
Either follow the guide to implement the functionality yourself or choose a new library, I decided to create a new library inspired by Lucia for anybody that wants something similar to what we currently have... |
Beta Was this translation helpful? Give feedback.
-
|
We've been using it for production for a while and we have no regrets. Even if lucia really becomes deprecated, the demos we've done to migrate to a stand alone internal packages was pretty easy to do. Don't be afraid of lucia just because of this announcement. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for sharing this, it helps to take decisions. For many years, I did my own auth. It was simple as I just had a few Use Cases to handle (my use cases). With I guess that I will go back to roll my own auth, and will read from time to time your articles to make sure I'm doing the right things. |
Beta Was this translation helpful? Give feedback.
-
|
I think that's probably optimistic - more likely they'll just shift to another library |
Beta Was this translation helpful? Give feedback.
-
|
For time constrained (and beginning) developers, that may be the wise thing to do. I'm eager to see how easy the migration to @pilcrowonpaper's new resources will be however from a Lucia auth setup, prior to making that decision. |
Beta Was this translation helpful? Give feedback.
-
|
I didn't see this coming but it does mirror how I used Lucia as a learning resource when I first implemented it. I think a further extension - and I'm happy to contribute the work here - to make it a fully robust learning resource would be a section on (purely ethical) vulnerability testing. Learning how to test your own server for things that shouldn't go wrong but do go wrong, before deployment. I also was on the end of the "Never roll your own auth" advice from more experienced devs, and it comes from a good place, but ime there's really no substitute for being curious and running negative tests against your own auth flow. |
Beta Was this translation helpful? Give feedback.
-
|
Would probably be better in the Copenhagen Book unless it's JS specific but that seems like a great resource to add |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all of the work you have done maintaining Lucia. It is understandable that supporting each database adapter and use case is unsustainable. This seemed like the direction for a long time now. Turning Lucia into an education only resource matches how I am currently using Lucia, however, I'm not sure how the new user experience will be. If the library became just interfaces and you had to bring your own database adapter, it might still be less intimidating for new users than "completely rolling your own auth". |
Beta Was this translation helpful? Give feedback.
-
|
I am currently at (new user) stage - as I am coming from the backend and learning sveltekit as I go while adding Lucia. It has let me get Auth up and running, really appreciated the abstraction as it was just in a sweet spot. Was just going on to implement throttling and email verification. Tbh I struggle with the new basic-api migration docs. I respect the decision to deprecate the library but Would be maybe nice to have a side by side comparison (red -, green +) on which bits are to be replaced by what. |
Beta Was this translation helpful? Give feedback.
-
yeah definitely agree with this, i'm in the same boat |
Beta Was this translation helpful? Give feedback.
-
|
[update] Took me about a week but I have successfully migrated to the new basic api - and refactored out of lucia - for my oauth. Pilcrow's github on the sveltekit example is the bomb. Now to work on the email part 😆 still have ways to go but I'm actually liking the new logic. I did have to replace |
Beta Was this translation helpful? Give feedback.
-
|
First of all, thank you so much for all your hard work on this library, @pilcrowonpaper Like so many others, I fell in love with Lucia because it strikes that perfect balance between exposing descriptive primitives and providing just the right amount of guidance to help you roll your own authentication. Here are a few thoughts from my side. As someone who teaches these concepts (among many other things) to students, I hope I'm not making too many assumptions in sharing my observations. After reading through your thoughts, two key things stand out to me: the curse of knowledge and open-source burnout. Curse of Knowledge: I compared Lucia's documentation for Next + my tutorial side by side to the new example-nextjs-email-password-2fa project and must say there is a huge knowledge gap between both approaches. When it comes to authentication, you're operating at an expert level — most others simply aren't. This is exactly why abstraction layers exist. It's like asking someone who developed an ORM to teach me how to build one from scratch. That would be great for learning, but I'd never use those low-level implementations in my own project. (And yes, perhaps ORM is the wrong example here, thinking about all the anti ORM debates.) I follow you on X and often see you nerding out over encryption, which I love, hence the follow! But, to be honest, I don’t understand most of it. I operate at a higher level, and I believe many others using Lucia are in the same boat. Just by looking at the session.ts, I see so many things that could go wrong here:
So while you can implement authentication at a lower level, not everyone who touches authentication briefly in a project and then moves on to other things can do the same. So coming back to a hand rolled authentication layer in any project must be a painful experience if it is implemented on such a low level. OSS Burnout: I think one of the biggest time sinks for you must be maintaining all the different documentations/implementations across frameworks/ORMs. I really believe your recent decision to remove the adapters was the right call (#1639). My guess is that this is a key bottleneck that still needs further attention. After all, there should be more community involvement in maintaining adapters for popular ORMs, ideally by a team acting as a bridge between Lucia and the ORM. The same should apply to the glue code between frameworks and Lucia. Handling all these moving parts alone is simply too much. Offloading this burden — whether by starting from a cleaner slate by removing lots of it or involving reliable contributors — seems crucial (though I know, easier said than done). So yeah, as I said in the beginning: many of us were drawn to Lucia because it found that sweet spot between the framework, ORM/DB, and its own descriptive yet powerful primitives. The bonus was the way it taught the inner workings of the authentication layer. By striking the right difficulty (see Flow by Mihaly Csikszentmihalyi), you made it accessible for people to follow along. If you were to remove the higher-level primitives from Lucia, I suspect fewer people would use it as their go-to authentication layer and instead treat it more as learning material. That’s totally fine if your goal is to focus on education, but I believe Lucia is just getting started in the contested field of authentication solutions.
|
Beta Was this translation helpful? Give feedback.
-
|
For me, without the database adapter, Lucia is the verge on complicated to warrant a library and simple enough to write it from scratch. Ultimately though, Uint8Array operations and hashing are common at Lucia's level (even with the package) and the date time operation is something you write once and forget. The upcoming temporal API will help too |
Beta Was this translation helpful? Give feedback.
-
|
Like I could see how a full blown auth framework would be useful. But Lucia isn't that. It only handles sessions and you still need to implement the rest from scratch. |
Beta Was this translation helpful? Give feedback.
-
|
I concur with the thoughts @rwieruch shared. @pilcrowonpaper what would your view be on a middle ground API in which consumers provide their own DB logic in callbacks? That approach seems like it might balance the usefulness of Lucia's abstractions with the ever-changing landscape of ORMs. I happen to have the time and space to put together an example of this, if that sounds appealing. |
Beta Was this translation helpful? Give feedback.
-
|
I put this together with same thinking! https://github.com/gnk-softworks/narvik |
Beta Was this translation helpful? Give feedback.
-
|
@pilcrowonpaper I thought more on making the callback-based interface, and I've come to the same conclusion you reached. I think your idea to deprecate the library and replace it with guides and examples is a really good call. Thanks for all your work on it, your other libraries, and especially the Copenhagen book! |
Beta Was this translation helpful? Give feedback.
-
|
I'm really sad to see this announcement. Agree with everything @rwieruch said above. Lucia has been my go-to for the last few projects (also published a dynamodb adapter), and I have frequently been recommending it to others as "The best auth library I've ever used". Would there be a consideration to switching the current library to 0BSD, the same as the "new" guide version, to make it easier for others to fork and continue on your work (probably with the removal of users as the first port of call)? Regardless of where the project goes, thanks for creating (and continuing to create) great resources and projects! |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, I don't think I can legally make Lucia the package 0BSD. Users contributed under the assumption that the library will be released as MIT licensed, and I'd need to get approval from all past contributors if I want to change the license |
Beta Was this translation helpful? Give feedback.
-
|
I'm not so familiar with licenses, can I now fork lucia and keep going legally after you deprecate it? |
Beta Was this translation helpful? Give feedback.
-
|
I believe you can fork it, but the license will need to remain the same. To be honest, this was my intention too but I'm starting to think maybe starting from scratch with a new library that's cc0 licensed and does away with the adapters design may be the best way to go long term... Ideally still follow a lot of the same principles as lucia and utilise some of the other packages by pilcrow. More of a spiritual successor than a fork. |
Beta Was this translation helpful? Give feedback.
-
|
Forking MIT licensed projects is absolutely possible and the derived project doesn't have to be licensed under MIT either. The only condition is that the original MIT license text is included in the fork somewhere. |
Beta Was this translation helpful? Give feedback.
-
|
https://www.npmjs.com/package/narvik Decided on the fresh implementation approach. Decoupled from the data layer (pass in your own functions to handle data management). It’s in a basic but functional state. I’ll keep developing it for my own projects and anyone else who wants to use it. |
Beta Was this translation helpful? Give feedback.
-
|
Like everyone, I really appreciate your efforts @pilcrowonpaper. I've been using Lucia with Prisma in my SvelteKit apps and it worked really well. I guess I'll now build on your work to create my own library. |
Beta Was this translation helpful? Give feedback.
-
|
how do we implement auth now? I understand you are saying everyone should do from scratch but how do we do it? where do we start? |
Beta Was this translation helpful? Give feedback.
-
|
It's Cloudflare doing weird stuff in my region. I have the same problem with many sites, sitting behind cloudflare. |
Beta Was this translation helpful? Give feedback.
-
|
The rest of the error page: |
Beta Was this translation helpful? Give feedback.
-
|
In Firefox
|
Beta Was this translation helpful? Give feedback.
-
|
Okay, for some reason this only works for some of the pages. Weird shit like this, is one of the main reasons, I don't rely on 3rd. party providers for anything. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I found the right combination, finally. This seems to work on https://lucia-next.pages.dev/sessions/basic-api/ and a few other sites that had problems previously.
|
Beta Was this translation helpful? Give feedback.
-
|
I totally get this move , adapters are pain to manage especially for orms they change a lot also doing auth yourself is not that hard and if you don't want to redo the same process for each project create a starter kit. |
Beta Was this translation helpful? Give feedback.
-
How do you make starter kits? Do you mean preset repo with a whole frontend and backen framework? Like supersaas etc? |
Beta Was this translation helpful? Give feedback.
-
|
You create a cli that creates for you a base project structure with technologies you like using. i hv created one to start a project with sveltekit, typescript, tailwind, lucia, drizzle or prisma , express and socketio For the next version i need to remove lucia and replace express with hono. |
Beta Was this translation helpful? Give feedback.
-
|
This suggestion is kind of joking but also not really: A Sad to see this as a Lucia user/fan, I think there's definitely an audience for something plug-and-play like Lucia the library today. But as a @pilcrowonpaper fan I also understand the frustration that comes with maintaining something you wouldn't even recommend to others, and am excited for you to continue exploring in a new direction. |
Beta Was this translation helpful? Give feedback.
-
Could also simply just |
Beta Was this translation helpful? Give feedback.
-
|
i second this idea. I recently used and implemented lucia with oauth and session based auth. It took a bit of time, but the docs helped a lot. for adapters, i think interface that we have to implement and provide as a data adapter layer is a better idea? that way its customizable and easy for people to use. And you could just provide concrete implementaiton for drizzle and prisma. A cli would be great to get it deployed to start with the best standards and then we could change as we need it. |
Beta Was this translation helpful? Give feedback.
-
It could also just |
Beta Was this translation helpful? Give feedback.
-
It does not have to be a full init, it could add only what is needed. Something like |
Beta Was this translation helpful? Give feedback.
-
|
You can now run |
Beta Was this translation helpful? Give feedback.
-
|
Oh man! Just finished my first GitHub login in my app and came across this news, so sad! Are Maintaining the Database adapters the problem or Lucia itself? |
Beta Was this translation helpful? Give feedback.
-
|
@pilcrowonpaper's up and coming expertise in this area is exceptional. I think this is a good compromise between not having to carry the open-source maintenance burden (believe me, I understand this fully. I've been extremely vocal about this in the past) and helping the community to step up their auth game. It is inspiring and motivating. You want this resource to be out there! Whatever you decide to do, it's probably going to be helpful for many! I know there has been critique on Auth.js and am very open to collaboration, if it would ever come to that. I never saw this project as a competition, rather a different approach. Choosing between lower and higher level abstractions. Fun fact: When I first saw @pilcrowonpaper's library names, I chuckled. I come from Hungary, but now am a citizen of 🇳🇴. I live in |
Beta Was this translation helpful? Give feedback.
-
|
For anyone interested in a more “library-style” experience compared to Lucia’s new doc/guide format, I’ve started a fresh implementation (to avoid license issues) of a library called “Narvik.” It’s similar to Lucia, but the big difference is that Narvik is decoupled from the data layer—meaning you pass in your own functions to handle data storage. It’s still in a basic, functional state, but I’ll keep developing it for my own projects and anyone else who wants to use it. Contributors are definitely welcome! GitHub: https://github.com/gnk-softworks/narvik |
Beta Was this translation helpful? Give feedback.
-
|
Hi feedback from a dev here who has been using Lucia for a while. I have developed a Nuxt module with Lucia long time ago: https://github.com/wefixers/nuxt-lucia-auth I have abandoned the idea cause Lucia get in the way so much it's actually counterproductive. Delete and setting cookie is mhe, as I can easily write a middleware myself: export default eventHandler(async (event) => {
const id = getHeader(event, 'auth')
if (id) {
const userAndSession = await getUserSessionFromDatabase(id)
event.context.session = userAndSession || null
....
}
})I almost always rewrite the adapter cause i need custom logic in there 99% of the time, most of the adapter feature are useless. For example, deleting all expired sessions is trivial, if I have the skill to write a CRON job, certainly I have the skill to write a boring SQL query. Password reset and email is framework dependent, you either write a token on the DB or use a signed URL (yhe I've seen this on some other major framework out there), both things that either I want a framework to do it for me or I just gonna do it myself and use a library only for utility, not for logic. Arctic is kinda nice tho, I use it by itself without Lucia. So basically, I am in favor of having more of a learning resource rather than a library, with code examples that can be copy-pasted then modified and implemented properly by the dev. Final thoughtsOne final note, community and packages will be created sprouting from the learning resource, thus I would not exclude the idea of experimenting with providing a framework/library for major frameworks like Nuxt, Astro, etc. Here's the reason, implementation details matter, on a learning resource it's okay to gloss over implementation, but in real life application it's not. For example: https://lucia-auth.com/getting-started/nuxt export default defineEventHandler(async (event) => {
...
return event.node.res.writeHead(403).end();This is a bad idea in practice, you should Performing CSRF checks on non form requests is also problematic, as in theory you need CSRF check on all requests, but in practice, you only need it on the only 2 type form requests (browser are non-standard to keep the world a safe place). Also origin check for CSRF is debatable and bla bla bla that's not the point. I feel a library is critical to ensure the learning resource is actually useful in practice. Having just a demo or example would not do it. Hello!I hope this feedback is useful! |
Beta Was this translation helpful? Give feedback.
-
|
It is rare to find feedback like this. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all your work and crystal clear docs. Maybe (I know, easier said then done) the community can pick it up with you left off? I see other libraries were mentionned. I used https://github.com/simov/grant before, it's similar to oslo which is also low level and very thin. Maybe that too will interest some users here. Cheers! Lucia is dead, long live lucia! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @pilcrowonpaper, thank you for working on this libraries and auth in general, in a space that has been invaded by auth SaaS, your efforts have been noticed and appreciated by many ! I think a lot of users will have trouble agreeing with your decision because they find value in Lucia currently. I have a suggestion for you : Since you are planning on continuing with Oslo and Arctic, consider rebranding everything under the Lucia brand. Something in these lines :
That way you get all the benefits of small tree-shakeable exports, brand consolidation, you can keep framework/db specific snippets that can be copy-pasted by users on a Lucia website, get rid of adapters, provide a clear migration path to users, unify the docs and keep the stronger brand alive (Lucia > oslo > arctic). Additonally in the possible future directions for Lucia, I think a bunch of people have good ideas in this thread, like a CLI/shadcn like snippets. |
Beta Was this translation helpful? Give feedback.
-
|
There is some code from the new examples that's rather self-contained auth code and would be nice to make available in Oslo or elsewhere so that users don't have to copy/paste it too many times or think too much about auth fundamentals. Examples: |
Beta Was this translation helpful? Give feedback.
-
|
Honestly, a weird decision. I get it, ORM support is annoying, but abandon such a popular library? Weird choice. Hope you will listen advices on making a CLI (with starter, don't care about more complex usecases), otherwise someone else will profit from it. Anyway, good luck and thanks. |
Beta Was this translation helpful? Give feedback.
-
|
The decision seems a bit weird for me tbh, but anyways thank you for all of your hard-works to create a top-tier auth library and all the best with your future decision ! 🥇 |
Beta Was this translation helpful? Give feedback.
-
|
I think taking this approach is a good idea. Like |
Beta Was this translation helpful? Give feedback.
-
|
Lucia has been the best auth library I’ve used, hands down. You’ve done an amazing job with it, and I’ve really appreciated all your hard work over the years. I support you 100% on this shift – it makes total sense to focus on making auth simpler and more accessible through a learning resource. Thanks for everything you’ve built and shared with us. Looking forward to what comes next! PS : Maybe rolling our own auth (the right way) is the friend we made along the way. |
Beta Was this translation helpful? Give feedback.
-
|
Grateful for your work @pilcrowonpaper. Did non-managed auth for the first time using Lucia and its documentation, as well as that of complementary packages oslo and arctic have been very educational. Will explore some of the other options in the months to come. |
Beta Was this translation helpful? Give feedback.
-
|
relax guys, it took me maybe 10-20 minutes to the code examples in the https://lucia-next.pages.dev/ link and refactored away from lucia: webdevcody/wdc-saas-starter-kit@49e2d8f you can do this. |
Beta Was this translation helpful? Give feedback.
-
|
nice, thanks |
Beta Was this translation helpful? Give feedback.
-
|
Just want to throw this one out there. Could you please add a how-to to use with JWT? I know quite a few people have asked since the inception of Lucia. I think it would be beneficial and also a good learning experience of those who want to implement it [like me] but unsure of how to implement with best practices as well. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
That's why I've never used it from the get-go. Libraries come and go. Especially one man projects. Said to hear that, but maybe its for better |
Beta Was this translation helpful? Give feedback.
-
|
I don't wanna be a downer, but Better Auth is also one talented young dev from Addis Ababa (Ethopia). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your help in migrating away from Lucia. While it was a bit of work to integrate this as a barebones auth setup, I appreciate that the groundwork I did to set it up made it all the much easier to strip it out and create my own auth management based on your guide. As a suggestion, I'd ask you to reference in your docs or link to parts of Oslo you used such as for cookie defaults, as well as auth token parsing off the header for API calls. Thanks @pilcrowonpaper Another small point which was easy to miss, but the encoding of the token and subsequent re-use of the token to create cookies, I flubbed this initially creating cookies with the session.id on subsequent auth checks after initial create. I sat wondering how can I decode the session ID back to a token?? Then realized I can just re-use the token on the way in from the cookie value at the start of the request. |
Beta Was this translation helpful? Give feedback.
and others
-
I am planning to deprecate the library early next year.
It has become abundantly clear to me that Lucia, in the current state, is not working. I now implement sessions from scratch and don't use the library for my personal projects.
Lucia will be an open source resource on implementing auth with JavaScript. Instead of installing a package, you'll learn how to implement sessions from scratch. Here's an early preview. I think the session code is very simple and easy to understand. As an added bonus, I've added more fully fledged examples with 2FA, password reset, email verification, rate limiting, and passkeys. The Discord server will be just for asking general auth questions (so pretty much unchanged).
Database adapters have been a significant complexity tax on the library. It doesn't help that we need them to support a flexible schema. The library is too low level and simple for the burden to be worthwhile. From a maintenance perspective, a lot of database drivers aren't 1.0 yet, and even if their runtime APIs were relatively stable, their types were not.
I could make Lucia into something more of a framework, akin to Auth.js. However, they come with their own issues on top of Lucia's, and it should be its own package anyway.
Unless there are major objections, I will be replacing the current version next week. Libraries are flashy and marketable. But I am confident that Lucia will work better long term as a learning resource. v3 will be maintained for another 6 months or so, though the adapters may be deprecated earlier. The migration process should be relatively painless (no changes to database schema) and in fact easier than past major updates.
Beta Was this translation helpful? Give feedback.
All reactions