8000 In-built Authentication in SvelteKit · Issue #12511 · sveltejs/kit · GitHub
[go: up one dir, main page]

Skip to content

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

Closed
CordialGit opened this issue Jul 28, 2024 · 7 comments
Closed

In-built Authentication in SvelteKit #12511

CordialGit opened this issue Jul 28, 2024 · 7 comments
Labels
feature / enhancement New feature or request

Comments

@CordialGit
Copy link

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

@eltigerchino eltigerchino added the feature / enhancement New feature or request label Jul 28, 2024
@jorgelaranjo
Copy link

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?

@CordialGit
Copy link
Author
8000 CordialGit commented Jul 29, 2024

If you can add your own authentication why would Sveltekit bring something like that?

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.

At times it's not required

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.

and when required various people will have their own preference anyway being a library or oauth2 provider?

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.

@jorgelaranjo
Copy link

It's understandable to seek built-in authentication for a smoother development experience in SvelteKit, much like the ecosystems in WordPress, Laravel and Django. However, integrating authentication directly into SvelteKit may not be the best approach.

Here are some considerations:

Security Concerns

Authentication is a critical aspect of any application, requiring constant updates and monitoring to ensure security against evolving threats. Dedicated authentication providers like Cognito, Auth0, and Azure AD B2C offer robust security features that are challenging to replicate in a framework like SvelteKit. These providers specialise in:

  • Multi-Factor Authentication (MFA): Enhancing security through additional verification steps.
  • Single Sign-On (SSO): Simplifying user access across multiple applications.
  • Magic Links and Passkeys: Modern and secure authentication methods.

Complexity and Maintenance

Incorporating a built-in authentication system would introduce significant complexity:

  • Token Management: Handling token validity, expiration, and invalidation.
  • User Management: Supporting features like team-based user creation, password resets, and invitation tokens.
  • Logging and Monitoring: Ensuring comprehensive logging for audit and troubleshooting purposes.
  • Integration: Seamless integration with other security measures like firewalls and IP controls.

Flexibility

Developers have diverse preferences and requirements for authentication systems. An in-built solution might not cater to everyone's needs, leading to the following:

  • Limited Customization: Built-in solutions often lack the flexibility and customization ### Existing Solutions

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:

  • Opt for Ease of Use: With solutions like AuthJS for quick setups.
  • Favor Extensibility: With solutions like Lucia for more customized authentication flows.

Conclusionoptions offered by specialized providers.

  • Vendor Lock-in: Developers might be forced to use the built-in system, limiting their ability to choose a solution that best fits their specific use case.

Existing Solutions

Developers 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:

  • Opt for Ease of Use: With solutions like AuthJS for quick setups.
  • Favor Extensibility: With solutions like Lucia for more customised authentication flows.

In conclusion

While the idea of built-in authentication in SvelteKit is appealing, the practical considerations around security, complexity, and flexibility suggest that relying on established authentication providers is a more prudent approach. These providers offer tried and trusted solutions, ensuring robust security and feature-rich authentication that would be challenging to replicate within the SvelteKit framework.

By leveraging external authentication providers, SvelteKit can maintain its focus on being a powerful and flexible tool for building modern web applications, while developers can benefit from the best-in-class security and features offered by dedicated authentication services.

@dominikg
Copy link
Member

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.

8000
@david-plugge
Copy link
Contributor

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

@rChaoz
Copy link
Contributor
rChaoz commented Aug 4, 2024

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 handle hook. More specifically, I'd love to see a new auth function, similar to the load function, that is guaranteed to be called. It should be able to either redirect or confirm that the user is authed and return some data, like user ID, that can then be used by the load functions.

@benmccann
Copy link
Member

We will be adding support for Lucia. Please see svelte-add/svelte-add#543

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature / enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants
0