-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
In-built Authentication in SvelteKit #12511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
If you can add your own authentication why would Sveltekit bring something that at times is not required and when required various people will have their own preference anyway being a library or oauth2 provider? |
You see, when people want to build serious Projects that will enter Production, they don't want to experiment: they simply want to use tried and trusted tools, and be done with it. As an Example, you use SvelteKit to start a new Svelte Project. But there is the alternative to use Vite, or other plugins. Yet, every Svelte user will use SvelteKit and be done with it, because it is the approach that makes the most sense, and makes for easier workflow. It makes the most sense because SvelteKit will work seamlessly and compatibly with Svelte, and you will only worry about One(1) Update cycle, plus all the other internal toolings will cause a smooth ergonomic workflow for you. Rather than using Non in-built tools that will give you multiple Update cycles, compatibility issues, possible performance nightmares, and other whatnots.
Svelte has Transitions in-built. This doesn't mean that I will use Svelte Transition feature in my Projects: I could simply use a CSS transition and animation and be fine. Yet it's a sweet thing that the Transitions feature is in Svelte -- in which case I don't have to worry about Third Party transition libraries like Motion One, Framer and so on. My point here is-- Svelte as a tool is Modular: you simply will not enable the features you don't need.
If Svelte has in-built Authentication, those who want to use it will use it. Lucia is flexible, but takes effort to set up AuthJS comes more out of the box, but is harder to extend it to do something it doesn't do itself compared to Lucia. AuthJS is also opinionated, and actively pushes you away from old fashioned username/password logins model. Now, in learning from these two systems ( Lucia / AuthJS ), Svelte can have something in-built that is the best of both worlds : a simple Authentication system like AuthJS with the flexibility and extensibility of Lucia, and this automatically becomes a Third Authentication option for Svelte Developers. Now, when Svelte's in-built Authentication system comes upstream, most people will switch to it, and it will become Option One(1) for Svelte users, because as I have said before, people will naturally work with in-built tools because of the convenience and comfort it brings, and would not bother about learning Third Party tools. The beauty is that Svelte can make it simple to set up, and also give it magic powers to connect to third party providers, if that is the approach a Svelte user wants as his Authentication model. You see, having Authentication in-built in Svelte, doesn't mean you need to use it. You can ignore it if you choose, but it will make for a sensible workflow if you use in-built tools of a system when you need it. |
It's understandable to seek built-in authentication for a smoother development experience in Here are some considerations: Security ConcernsAuthentication is a critical aspect of any application, requiring constant updates and monitoring to ensure security against evolving threats. Dedicated authentication providers like
Complexity and MaintenanceIncorporating a built-in authentication system would introduce significant complexity:
FlexibilityDevelopers have diverse preferences and requirements for authentication systems. An in-built solution might not cater to everyone's needs, leading to the following:
SvelteKit is designed to be modular and flexible. Developers can choose the authentication library or provider that best suits their project's needs. Libraries like AuthJS and Lucia offer varying levels of simplicity and flexibility, allowing developers to:
Conclusionoptions offered by specialized providers.
Existing SolutionsDevelopers can choose the authentication library or provider that best suits their project's needs. Libraries like AuthJS and Lucia, as you already said, offer varying levels of simplicity and flexibility, allowing developers to:
In conclusionWhile the idea of built-in authentication in By leveraging external authentication providers, |
there is also svelte-add which is under active development again, so please raise your voice for auth solutions there too. In the future svelte-add could be integrated tighter with create-svelte, so that you'll be able to pick an auth solution when starting a new app. https://github.com/svelte-add/svelte-add One thing sveltekit can do (and is on our radar already) is providing more/better low-level apis for these to implement features that improve DX. Adding a high level first party auth solution into sveltekit itself is just too much work and it is impossible to fit everyones needs. |
If you provide a builtin auth you would also have to choose a database and probably cache. Making all that stuff modular would be kinda hard in the rapidly evolving ecosystem |
I think providing authentication as a whole is too much. But I would love if we got some way to protect routes rather than manually checking the path in the |
We will be adding support for Lucia. Please see svelte-add/svelte-add#543 |
Describe the problem
I come from WordPress, and the ecosystem of WordPress has grown vast.
Now, to add functionality to your WordPress website, you need to add a plugin.
But more plugins from different third parties, means that you have compatibility issues because each plugin passes through a different Update cycle.
Again, more plugins also means that your website could load slow, thus you suffer performance issues.
A way that many of us mitigate against this downside, is to use things called Page Builders, like:
-- Elementor ( https://elementor.com )
-- Divi Builder ( https://www.elegantthemes.com/gallery/divi )
-- Visual Composer ( https://visualcomposer.com )
And so on.
The reason why this is a smart move, is because these are just one plugin that would come with more than 100+ features and functionalities that we would have needed a 100+ plugins to achieve.
And as such, there is performance improvements on our WordPress websites.
USEFUL EXAMPLES
Whether you use AdonisJS, Laravel or Python's Django framework, these tools come with Authentication in-built.
You don't need an external Authentication library to get Authentication in your Application, when using Adonis.JS, Laravel or Python's Django framework.
THE REQUEST
Rather than us searching for Authentication Libraries, and deciding whether AuthJS or Lucia Auth is the best Authentication system for our Project, I am proposing that SvelteKit should provide in-built Authentication system.
You see, in my opinion and for good Developer Experience, it is hard learning too many third party things for just a simple feature that can be in-built.
Authentication is a normal thing for a Production grade Application that SvelteKit wants us to build.
SvelteKit needs to come with an in-built Authentication system for us to secure our Production Applications, just as AdonisJs, Laravel or Python's Django framework have done.
Regards.
Describe the proposed solution
I would like to see my learning curve reduced, by SvelteKit having an in-built Authentication system.
Alternatives considered
Adonis.JS, Laravel or Python's Django framework.
Importance
would make my life easier
Additional Information
No response
The text was updated successfully, but these errors were encountered: