Rethinking and rebuilding Lucia

[pilcrowonpaper]

Hello!

As usual, let me start off by saying thank you for the continued support for Lucia! It's been one of the most rewarding experience!

If you've looked at the repo recently, you might've noticed documentation-beta dir. With SvelteKit and Lucia being quite stable, I've decided to rewrite the documentation and rebuild the website. Or that was the original plan. As I was rewriting the docs, I began to wonder if the current approach is the best, looking both from a security perspective and a developer perspective. And, I do think it's "good enough," but there's a lot of room for improvements.

tldr; I'll be moving Lucia to use session tokens instead of JWTs and move to cookie based authentication, which would allow the API to be much simpler. While some changes to the database is necessary, no user data will have to be moved in the process.

Tokens

Are tokens necessary? Well, yes, of course, but does it need to be exposed to the client? In the current set-up, you send the access token via the authorization header or inside a hidden form input. This prevents CSRF attacks but it's tedious to add them to every requests and the auto-refresh mechanism has been quite problematic in the past. What if we can completely forget about them in the client? Well, we can do that using httpOnly cookies. I've avoided them because it can be vulnerable to CSRF attacks on its own but, by making sure the request came from a trusted domain (check the Origin header, supported by all modern browsers since Nov. 2019), it’s now possible to prevent CSRF without any additional tokens. While it's possible to forge request headers outside of browsers, you'd still need the token value and this is the same when using the authorization header. By moving to this approach, it completely eliminates the risk of tokens stolen via XSS.

Another issue with the current approach is that users can't have multiple tabs opened at once. There's no way to "listen" for cookie updates and as such, Lucia will refresh the tokens regardless if another tab has already refreshed the token. But, the current refresh token would be outdated and the session will fail to renew. Only using cookies will make all refresh attempt successful since the cookies are shared across tabs.

JWTs

This is a big one. Is JWT secure enough? My answer was "yes" when I started but I'm having my doubts. Right now, I think it's an ok choice for authentication, but inadequate for authorization. So good enough for checking if the user is who they claim to be, better to avoid for checking if the user has access to some resource. And that downside, that JWTs cannot be changed or revoked immediately, is a big one. On the other hand, JWT's biggest advantage, that it reduces the latency of API requests, is not too important, especially if you have a fast database close to your main server.

So what's next?

In the next few days, I'll continue building the update and will post another discussion sharing what will change exactly. I'll be updating the docs and every community maintained adapters as well. This will be the upmost priority and all focus will be on it. This change will invalidate all user sessions but they will be able to re-login since this update will leave the user table alone.

Thank you for sticking with me and I hope this update will make Lucia an even better project!

[seb-lewis]

Looking forward to the upcoming changes. Here's to hoping session tokens become the standard 🍻

[asuraphel]

It would be nice if session backend is configurable. Eg. allow Redis for session storage. https://pypi.org/project/starsessions/1.2.3/ is a good example.

[asuraphel]

Wouldn't validateRequest validate the access token too?

[pilcrowonpaper]

Yeah, need a better name for that. It just does a csrf check and get the tokens from the cookie. Lucia needs to get the current user for the session store and getting the current session and then the user seems inefficient.

[pilcrowonpaper]

Getting the current user is such a common use case so I kinda need to make it easy/fast

[asuraphel]

I think validateCSRFToken might be a better name and should only do that and not return the tokens iMO. BTW is it possible to pass csrf token via JSON instead of FormData? Making POST with JSON payload is common..

[pilcrowonpaper]

There's no CSRF tokens, it just checks for the Origin header.

You can validate POST requests using validateRequest (not validateRequestByCookie), which takes in the access token inside the authorization header.

[etmartinkazoo]

This is such a great library; I'm using it for an app in production so a big thank you @pilcrowonpaper

You mentioned Authorization here and I was wondering if you had any strategies in that regard; namely do you recommend another library or do you just create some classes and roll it yourself.

Thanks!

[chakrihacker]

Any update on this??
Can you still provide an option to use JWTs??

[subhasishdasfreelance]

In my case I'd also like a JWT option. Because I would like to use it without a database. Right now I can't find a way to do it.

[AlexErrant]

Seems unlikely #1361 (reply in thread)

[maxpaleo]

@pilcrowonpaper , this lib has really been taking off, but please do something about the documentation. It's so unclear and most of is to generic which makes it quite confusing. A basic example: how on earth do I set a new cookie with a different name? Nothing mentions adding more than one cookie or changing the default cookie name from auth_session.

It'd be so much clearer for everyone using this if the docs where more consice, offered more examples, and also use JS docs directly in the lib to immediately get a description of what each function does without having to consult the documentation.