A fresh start

[pilcrowonpaper]

It's official - I'll be deprecating Lucia v3 by March 2025.

• lucia NPM package will be maintained until March (mostly bug fixes)
• For the adapters, I will only fix issues open right now. They will all be deprecated by the end of 2024.
• Example projects and the v3 docs will no longer be updated aside from some quick fixes.
• All my other libraries, including Oslo and Arctic will be maintained and developed.
• I will continue to operate the Discord server.

The v3 docs is available at v3.lucia-auth.com.

---

Lucia is now a learning resource on implementing auth from scratch. You'll essentially recreate Lucia v3 in your project - just without all the bloat that came with supporting various runtimes and database. The code is actually very short and simple, and as a bonus, infinitely customizable. Everything is available at lucia-auth.com.

The goal of Lucia v3 was to be the easiest and cleanest way to implement database-backed sessions in your projects. It didn't have to be a library. I just assumed that a library will be the answer. But I ultimately came to conclusion that my assumption was wrong. I don't see this change as me abandoning the project. In fact, I think it's a step forward. If implementing sessions wasn't easy, I wouldn't be deprecating the package.

But why wouldn't a library be the answer? It seems like a such an obvious answer. One word - database. I talked about how database adapters were a significant complexity tax to the library. I think a lot of people interpreted that as maintenance burden on myself. That's not wrong, but the bigger issue is how the adapters limit the API. Adapters always felt like a black box to me as both an end user and a maintainer. It's very hard to design something clean around it and makes everything clunky and fragile, especially when you need to deal with TypeScript shenanigans.

Lucia was my first open source library, and I will forever cherish it for launching my open source work. I'll continue working on Oslo and Arctic, and I have a secret little project coming up that I think pairs really well with the new Lucia.

[sommeeeer]

Thank for you for an amazing library, and I support your decision.

[cannorin]

So long, and thanks for all the auth!

[Sammy-T]

Lol I was going to say something similar.

[ThimoDEV]

Thank you for your hard work on Lucia and your continued contributions around auth in the open source ecosystem. Really looking forward for whats to come!

[mehradamiri]

As long as the new documentation provides sufficient examples for different frameworks and includes clear, detailed information, I don’t think there’s a need for external libraries to handle authentication for you.

I liked Lucia because of its flexibility and simplicity, unlike many high-level auth libraries. With this new direction, I believe it’s even better. In my opinion, the power of Lucia was always its simplicity and flexibility, and this shift reinforces that.

[j3sch]

I really like your decision. Makes so much sense. Less bloat and more control ❤️

[astudentinearth]

Thanks for creating such an amazing library, which now serves as a great example on authentication.❤️

[thecodingmontana]

Thank you so much for introducing us to Lucia! 😊 I really struggled with Auth at first, but after deciding to use Lucia, I’ve come to truly appreciate Auth. Now that I’m following the Basic API and utilizing all the Auth-related resources you provided, I’m able to fully implement Auth. Big thanks! 🙌

[aloon]

Is there now an official way in Astro to handle authentication?
In the official Astro documentation Lucia is still listed as the first option

[keremtiryaki]

nope, "Lucia is now a learning resource"
Check new astro examples to learn how to do it yourself.
https://github.com/orgs/lucia-auth/repositories?q=astro

[RyzeKit]

Having recently converted my Astro starter kit to Lucia v4 with the help of those Astro examples, I can say that it definitely took some time to figure out how to implement it myself, but it was still doable, so feel free to give it a go 👍

[starlight-akouri]

Okay, so as someone working on a new project from scratch right now in Next.js, do we use Lucia? It's not really clear what a "learning resource" means. How is it different than the Copenhagen book?

There is still need for a decent auth library for this framework. The other one (next-auth) has gone to crap recently.

Thanks for all you've done in the auth/typescript space!

[pilcrowonpaper]

You just follow the guide in lucia-auth.com, specifically the basic API and cookies page

[ThimoDEV]

I saw that the Lucia package has a few more functions than what is documented till now on those pages. For example serialize cookie or create blank cookie for example. Will those also be documented on the lucia site?

[pilcrowonpaper]

@ThimoDEV It's documented here

https://lucia-auth.com/sessions/cookies/

[ThimoDEV]

Yes I saw those, I just had to look up some helper functions in the lucia package on github itself to complete the migration

[JulyWitch]

This is a better solution for end users as well 👌 Thank you for your efforts ❤️

[merthanmerter]

I think this is a great idea. In fact this is what the community needs more instead of a library to be honest.
I hope this will evolve in to a unique detailed source. Auth shouldn't be a paid service! Thank you for this amazing contribution!

[jv-aquino]

we support your decision and thanks for the library man! it helped me a lot to learn auth and that you can actually build something without just using clerk or supa auth, the way I did before

[davepar]

Really appreciated having Lucia when I was getting my project started. I'll probably switch to an Auth provider soon (don't want to deal with the complexities of passkey, social logins, etc.), but it was nice to have a simple username/password while I was bootstrapping the site.

[gene-git]

Followed your guide/guidance - and working great and learned lots more along the way. arctic remains incredibly invaluable for taking care of the 'hard' OAUTH parts.

I am using in house keycloak as our OIDC server. Our keycloak provides authorization roles as well as authentication and your tools and guidance were essential for getting to work - and work really, really well.

A very big thank you @pilcrowonpaper

[davepar]

I totally support your future plans, but I have one question. If I follow the new examples and implement them in my code (e.g. Passkeys), how will I know if a security issue is found in the examples in the future? Currently, libraries get updated and I pull in the new version. Unless I remember to check back occasionally, I'll never know if the example code is updated or fixed.

[SerJaimeLannister]

Agreed

[ajsohnsv]

@pilcrowonpaper

[EricGeek]

I also totally support your future plans. When the Svelte CLI sv added Lucia support (following your latest guidance), they locked it into drizzle support so that they wouldn't have to deal directly with supporting different databases. I have one idea, however, not sure I'd go so far as to call it a suggestion.

What would the pros and cons be of going with a shadcn-like approach, where rather than providing a Lucia library, you basically copy a lucia.js/ts file into your project that the dev is expected to edit? That file implements one database type of access with comments explaining what parts of the code need to change and what they need to do if you change the schema or type of the database. The bulk of the code would still be in arctic/oslo.

This means that the app dev would need to know how to talk to their database, but I think that would be a pretty low hurdle and wouldn't push you into supporting multiple databases. Heck, the baseline file could just support an in-memory data store of your own design to ensure that you don't have to update the file because the database it's based on updated something. It would also isolate you from "but you support DB XXX, why not DB YYY?"

The one con I see is the same thing @davepar pointed out, making it part of the app rather than a dependency means that updates to this one file would be harder to track. The other thing is that this file could be a third party file as easily as one of yours, so I could do it myself (or anyone else could) without placing the work on your shoulders.

And yes, I definitely owe you a big thank you for what work you've already put into this. My first OAuth implementation used arctic without Lucia (legacy login couldn't easily be hammered into something Lucia was happy with, which is exactly why I think this is the right move).

[draylegend]

that would eliminate the problem described by @davepar. Maintaining a package with a migration routine would solve many issues

[gene-git]

Suggestion:

Perhaps it would be helpful to have a new github discussion category here where people can offer code examples they have used to share with others. Can be snippets or entire working solutions.

Make it clear that @pilcrowonpaper is providing a place to share rather than endorsing whatever people share. Perhaps call it community examples or 'shared code' or something.

I think the best way for people to use this is then to put their code in their own github repo and add an item to the 'Shared Code' discussion with short explanation what is offered together with a link to their repo which provides the code.

Thoughts?

[EricGeek]

I actually agree with this. The more I thought on this, the more I realized I was really talking about a rather pedantic example rather than something that needed to be part of the base distribution.

[SerJaimeLannister]

I also agree with this.

[gene-git]

So @pilcrowonpaper - what do you think of this suggestion ?

[RyzeKit]

Just finished converting my Astro starter kit to Lucia v4. Although it took some time, the example projects were definitely very useful (at least the ones for Astro were), so I highly recommend developers check those out ❤️

[andrioid]

I ended with up less code and two less dependencies after migrating from a v3 Astro project. So, even though I had only used Lucia for a couple of weeks when this was announced, it was clearly a sound decision and helps developers take responsibility of their auth instead of relying on the library to do it.

Love the docs explained every step. Keep up the good work!

[Luigi123]

Yup, we also ended up with fewer dependencies and less glue code after migrating from Lucia v3 on our Next.js project.
I loved how just following the new docs gave us a straightforward auth library that we could package within a monorepo, leaving plenty of room for customization. We have two apps in our monorepo, each with its own auth requirements, and we managed to customize the API making it generic enough to suit our two (very different) use cases better.

Thanks so much for Lucia and for the fantastic documentation!

[rwieruch]

If someone needs to have a PR next to Lucia's migration docs that showcases the changes: rwieruch/the-road-to-next-app#9