auth.config.js and lucia auth
Hi!
I'm trying to setup Lucia auth on our project (I need full control over our OAuth connections), and followed and tweaked the guide that was created for Lucia V2 for V3. So far everything seems to work as expected.
I was wondering how the auth.config.js factors in though?
It doesn't quite matter for the stage I'm at now, but I want to ensure that we're following best practices security wise once I start moving this into production.
7 Replies
auth.config.jsis only used for our JWT-based integration. Lucia doesn't use JWTs (at least not in the template and library I put together). This also means that the built-in
ctx.auth object won't have any user identity in it (instead you'll fetch it manually at the start of each function via the session ID).Thank you @Michal Srb - that does make sense.
Everything is working well, but while the ease of passing sessionId's is great, I do worry about the security implications of it.
Since the sessionId will need to be sent as an argument to convex, and will need to be accessible n JS, it'll now be susceptible to client side attacks.
And unlike refresh tokens, sessionId's with Lucia are only ever extended and not invalidated (unless you log out)
https://security.stackexchange.com/questions/223002/session-id-in-custom-header#:~:text=Sending%20session%20tokens%20in%20custom,exceptionally%20vulnerable%20to%20token%20theft.
Information Security Stack Exchange
Session id in custom header
Is there a way to perform session fixation attack with XSS present if session id is passed in request header?
As far as I see it, theoretically there are three ways to do so:
intercept request on...
Something like this (which could relatively easily be handled with NextJS), also doesn't seem to be possible since the client needs to communicate directly with Convex:
https://medium.com/@benjamin.botto/secure-access-token-storage-with-single-page-applications-part-2-921fce24e1b5
I know it's been a discussion a few times before, but it does increasingly point towards Convex taking a stronger stance on what a convex first auth solution would look like.
I can afford to ignore this problem for now though, and will probably just revert to Clerk etc. to get a little added safety in the form of rotating refresh tokens.
Medium
Secure Access Token Storage with Single-Page Applications: Part 2
In my last article I went over some reasons for keeping access tokens out of the browser and presented a few attack vectors. In this…
Yes, XSS risk is called out here: https://www.npmjs.com/package/@convex-dev/convex-lucia-auth#note-on-csrf-protection
I wouldn't worry about it unless you're not using React or you're using
dangerouslySetInnerHTML in your app.
Clerk is also a fine solution!npm
@convex-dev/convex-lucia-auth
Convex database adapter for Lucia Auth. Latest version: 0.0.4, last published: 3 months ago. Start using @convex-dev/convex-lucia-auth in your project by running
npm i @convex-dev/convex-lucia-auth. There are no other projects in the npm registry using @convex-dev/convex-lucia-auth.One note around XSS and refresh tokens vs. session IDs since I was doing some thinking last night. Curious whether this resonates @The Aleks .
1. During an XSS attack, the user is just as powerful whether the token is client-persisted or not. Clerk exposes the
__session and __client tokens, but more importantly, any fetch from an XSS has full permissions.
2. After XSS has been discovered, patched, and deployed, the lasting impact is a matter of how fast you can invalidate the existing auth tokens.
a. With a JWT, this reduces to how long-lived the JWT token works for, since you can't invalidate them without doing a DB lookup for a blocklist - which defeats the point of a JWT.
b. With a session ID that is validated against a DB on every request, this reduces to whether you can invalidate those session IDs. Generally just deleteing the session documents / setting "invalid: true" on them can achieve this.
Interestingly, explicit session IDs is a faster remediation than JWTs. There are cases where it's still nice to rotate them - maybe the attacker can more easily use the long-lived token from their own machine until it's been invalidated e.g.
Furthermore, by storing something in localStorage, you eliminate the surface area of accidentally passing along a cookie through CSRF / etc. where the attacker doesn't have an XSS exploit.
It makes me think that having a "clearSessions" internalMutation on your dashboard gives you fast remediation potential than even 60s refresh tokens.
Now it's safe to use an auth company to make these tradeoffs for you and try to follow their best practices, but I'm not convinced that JWTs are actually what you want a lot of the time for API requests, if you have fast access a DB to do concrete validation.I read https://clerk.com/docs/security/xss-leak-protection#why-is-the-session-cookie-on-my-application-domain-not-http-only and https://github.com/orgs/clerk/discussions/336#discussioncomment-3442951
which informed some of this thinking
XSS leak protection | Clerk
Learn how Clerk prevents and mitigates XSS attacks.
GitHub
How is Clerk actually secure if the session in non-http? · clerk · ...
Sorry in advance if this is a dumb question, but in reading the docs for Clerk, apparently Clerk secures against XSS attacks by creating short-lived session access token (__session cookie). But, ho...
I appreciate you diving into this and doing some thinking on it.
I think it's easy to accept that "Clerk", "Kinde" and "Auth0" must have figured it out and as a result fail to actual introduce the diligence needed to make things safe.
One issue I see with the suggested Lucia Session implementation though:
If an attacker gets your sessionID, you won't know. So while stopping the attacker is easy, you might be oblivious to it for a long time.
This is one thing that rotating RefreshToken solves - which we obviously could do with SessionIds as well: We rotate them every 30 minutes.
Meaning either me or the attacker will be logged out when it rotates