What do you mean doesnt work?
Do you mean v1 will be deprecated or the full lucia project?

2 replies

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 validateRequest() function, and not have to worry too much about session management; Lucia was/is a really excellent and lightweight option that brought core functionality without too many extra / bloating bells and whistles.

Nonetheless, thanks for all the work you have put into the library and resources @pilcrowonpaper.

2 replies

I just planned to use lucia for the first time but I guess nope

6 replies

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).
In a lot of ressources on the web they say: "NEVER ROLL YOUR OWN AUTH"! And I understand because the topic is not so trivial, and the more use cases, the more things you need to cover.

With Lucia I felt that I was half covered by just using it, and I learned a lot by reading your nice articles. If there was something important, you (the expert) would raise it and I would update... nice and easy.
With the next approach, everyone will have to become a auth expert, read from time to time news about it & co. In a way it's good because it increases the knowledge of everyone, but it's also something on our plate again.

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.

2 replies

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.

1 reply

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".

3 replies

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:

• ms calculations that could go wrong without testing (-> more duplicated code in every project using "Lucia")
• usage of rarely used APIs (e.g. Uint8Array)
• usage of lower level library APIs (e.g. encodeBase32LowerCaseNoPadding, encodeHexLowerCase) which need explanation
• timestamp operations (i.e. subtraction) and comparisons
• ...

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.

5 replies

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!

5 replies

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?

9 replies

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.

2 replies

This suggestion is kind of joking but also not really: A npx lucia init workflow similar to shadcn, which implements the session logic directly in your codebase (say, src/lucia). Instead of being a library, the implementation details live in your codebase, for you to maintain. Some things can also be stubbed out for the user to hook up, like hooking into your specific database ORM.

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.

6 replies

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?

0 replies

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 thoughts

One 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 throw createError instead as .node.res is not available in all environments.

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!

1 reply

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!

0 replies

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.
That being said, personally I think that this is your open-source library and you are free to do whatever you want, altough I believe it's a shame for the Lucia name that was starting to get a lot of positive recognition as a library, as well as for you as a library author : this might hurt the adoption of your future projects.

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 :

• Arctic => @lucia/oauth
• Oslo => Lucia (@lucia/cookie ...)

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.

0 replies

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.

0 replies

I think taking this approach is a good idea. Like shadcn: at first it was just a place to copy past your code, later they created a CLI. Maybe an idea to develop a CLI? A CLI is also flashy and marketable. The shadcn for auth ;)

0 replies

1 reply

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

1 reply