Svelte Kit SuperTokens

Hello! This is my attempt at providing an example of how to use Svelte Kit (an amazing tool for building SSR web applications in Svelte) with SuperTokens (an open source alternative to user authentication). Note that this repository uses the EmailPassword recipe/approach from SuperTokens for its examples. However, the code here should be easily transferrable to the other authentication repices/methods that SuperTokens provides.

The solution here is based on my work done in the Remix version of this app, but it has been modified to be more accustomed to Svelte Kit. Note that this application takes an SSR-only approach for three reasons: 1) Better security (big plus), 2) Guaranteed progressive enhancement (also a big plus), and 3) Easier code management (arguably).

If there are any questions, concerns, or ideas for improvement, feel free to reach out to me in the SuperTokens Discord or the Svelte Discord. (Technically either one works. But if your question is more oriented towards SuperTokens, you should probably ping me on the SuperTokens Discord.) If you notice any problems with the example application, feel free to open an issue here on GitHub.

How to Run the App

Start the dev server by running npm run dev. Remember to add your own .env file to configure SuperTokens! You will need to configure:

• DOMAIN (e.g., http://localhost:5173)
• SUPERTOKENS_CONNECTION_URI (e.g., https://try.supertokens.com)
• SUPERTOKENS_API_KEY (optional if your SUPERTOKENS_CONNECTION_URI is https://try.supertokens.com)
• SUPERTOKENS_WEBSITE_DOMAIN (e.g., http://localhost:5173)
• SUPERTOKENS_API_DOMAIN (e.g., http://localhost:5173)
• SUPERTOKENS_API_BASE_PATH (e.g., /auth)

Frequently Asked Questions

Why Aren't You Using supertokens-website or supertokens-web-js?

Depending too much on supertokens-website or supertokens-web-js will result in an application that cannot run without JavaScript. And an application that can't run without JavaScript is actually inaccessible to a lot of users. Consequently, we've pursued a solution that works without these pacakages and without JavaScript. (Don't worry! We still enhance the app with JS to improve the user's experience whenever possible.) This means that our application will be accessible to the broadest range of users! :smile:

As an added bonus, we decrease our JS bundle size when we avoid the use of supertokens-website and especially supertokens-web-js.

Why Aren't You Using the Middleware from supertokens-node?

If you've seen the comments from @Rich-Harris (creator of Svelte) regarding server middleware (e.g., Express Middleware), then you'll know that solutions which require you to use middleware are often restricted and will prevent you from enhancing your application with other very important features. This is especially true if you're working with an SSR framework. Unfortunately, I have found Rich Harris's statements to be correct while working with my own Svelte Kit application. There are workarounds for these problem cases that allow people to still use middleware... but those aggressive workarounds often end up looking more ugly and complicated. (And thus, such approachs are more prone to error).

Avoiding the supertokens-node middleware ended up being required for me to use HTTPS in my application and get it working with high security in Cloudflare. I'll spare you the details, but there are other edge cases like these where supertokens-node middleware just won't work (or won't work well). Thankfully, in supertokens-node@14, the SuperTokens team was kind enough to introduce functions that allow you to get authentication working without using their custom middleware. If you're using any kind of SSR framework that leverages progressive enhancement (SvelteKit, Remix, SolidStart, etc.), then you'll want to leverage these functions instead of using the middleware as well.

Why Are You Using JSDocs Instead of TypeScript in Some Svelte Files?

Unfortunately, unlike Vue, Svelte does not support TypeScript type annotations in its markup (at the time of this writing). This is due to a limitation in how Svelte files are processed. However, you can use types in Svelte's markup if you use JSDocs (because JSDocs don't have to be processed by Svelte). Consequently, we use JSDocs in the Svelte files where we deemed in-markup TS types to make the code more readable.

You're free to change these files to use TypeScript if you like. However, you'll need to move all code requiring TS type annotations into the <script> section of your Svelte files.

Security Insights

Although the middleware-free approach gives us many advantages when it comes to using SuperTokens with SSR frameworks, it also gives us a little more responsibility. You'll notice in this app that we have to be intentional about the settings which we use for our HTTP cookies. You don't necessarily need to use the settings that I have (though you should use HttpOnly and you should set a strict Path), but you should certainly ensure that your settings are the safest that they can be for your application. Here are some resources that may be helpful for you on the matter:

• How the Set-Cookie HTTP Header Works
• Docs for the cookie NPM package (Svelte Kit uses this under the hood to set the options for its cookies)

Note that Svelte Kit provides some CSRF protection out of the box. (See sveltejs/kit#72 and sveltejs/kit#6510.) If you're interested in doing anything more, consider the following resources:

• Cross-Site Request Forgery Prevention Cheat Sheet

SuperTokens does have some anti-CSRF features, but there are cases where it should be used and cases where it need not be used. From @rishabhpoddar:

Basically, when you call createNewSessionWithoutRequestResponse, and if you get an anti csrf token, then you should pass that in when using getSessionWithoutRequestResponse. If you do not get an anti csrf token, you don't need it (based on your apiDomain and websiteDomain setting) and should check for custom request header before calling getSessionWithoutRequestResponse. You should not explicitly set the value of disableAntiCsrf when calling createNewSession unless you are not using cookies at all.

Bear in mind that if you're using a framework that (sufficiently) protects against CSRF by default, then you don't necessarily need to worry about the custom headers yourself.

I hope you find this useful! Let me know your thoughts here on GitHub or on their Discord. :) If there are any ways that I can improve anything here, feel free to say so.

# create a new project in the current directory
npm create svelte@latest

# create a new project in my-app
npm create svelte@latest my-app

npm run dev

# or start the server and open the app in a new browser tab
npm run dev -- --open

npm run build