RFC: An authentic authentication

[eric-burel]

Goal

Account system out of the box is one of the main love feature of Meteor.

Ideas, leads

Looking for a replacement to Meteor Accounts.

Pure soft implementation, like Passport, for a basic password auth? Support for 3rd party systems like FusionAuth?

Connect to Vulcan via oauth? And Vulcan as an oauth server?

Step 1: 2021

• [X] Demo private pages
• [X] Implement password change and password reset
• [X] Implement email verification
• [X] Easy oauth with usual providers => refer to Passport, which allow to add strategies easily
• [X] Auth server => with passport
• [X] Stop using localStorage for auth, including in Vulcan, use Set-Cookie instead
• [X] Create a function to check crendentials => necessary for the update password workflow
• [X] Create a token system for password reset, with a token sent via email => we need to create the token (see Blitz helper for instance) + store it in the user data. Then we can compare the provided token to the one in the db. We might also add additionnal securities like an expiration date. Ignore current code that uses the session token, it's simply the wrong kind of tokens. In the meantime cy.request does the job in test.
• [X] Add e2e tests for login, logout, signup, password change
• [X] Add e2e tests for email verification, password reset => ok for password reset, need to be done for user verfication
• [x] Add an SMTP server for email sending, or use console.log if none is set during development => started to work on it, not yet configurable (localhost only + setup in Cypress)

Step 2

• [ ] Add tests for API endpoints=> we wait for https://github.com/vercel/next.js/discussions/13389 and https://github.com/vercel/next.js/discussions/28173 to progress, so that we can test API routes more cleanly. Those discussions should bring ways to easily start and stop the Next server during testing, which is more efficient that trying to spawn a fake Express server. Tests are located in our .vn folder.
• [ ] Add API test for error scenarios: trying to reuse the same token twice
• [ ] Provide auth components like in Vulcan => ongoing work, we still lack role based + more example (currently, the useUser hook has an option to trigger a redirect if there is/there is no user, but that's simplistic and a tad confusing)
• [ ] Refactor by wrapping reusable methods into services (both client side and server side) => on progress, using an "account" lib + the User model. Responsibility of each is not completely clear yet however.
• [ ] E2E tests are working but sometimes flaky, in particular the token is sometimes wrongly considered as expired already. Maybe the page is loaded twice by Next during dev? To be investigated.

State of the art

•  Blitz.js has a cool demo and secure setup
• Auth js => we could reuse the token based methods from this library
• Vulcan implementation => we can take inspiration from the logic there, but we need to reimplement the lower level primitives out of Meteor
• Frame project
• Email verification question on SO
• Hackathon starter
• Next auth
• Apollo example with auth
• Our own issue about private pages
• React Roles

[eric-burel]

Regarding private pages, it needs #49 and #71 needs to progress a bit until we get a proper architecture.

[eric-burel]

Regarding role management, we should probably keep Vulcan NPM as-is: simply include "guests" (or "anyone"), "members" and "admin" groups. Then, instead of trying to add groups into Vulcan, we could make it possible to build a role based security system inside Vulcan Next instead.

[eric-burel]

@Timi-Duban in the short run, we would need to add new endpoint to have the same features as described here in VulcanMeteor: https://github.com/VulcanJS/Vulcan/blob/devel/packages/vulcan-users/lib/server/mutations.js

In Vulcan Meteor, we rely on Meteor Accounts (see https://github.com/VulcanJS/Vulcan/blob/devel/packages/vulcan-users/lib/server/AuthPassword.js).

In Vulcan Next, we rely on passport, so lower level but more powerful library. Also, currently, we don't use graphql for auth, but normal REST endpoint (see existing entry points for "logout", "login", and "signup") => we can keep doing that for now.

The most difficult part is handling e-mails, for user verification ,password change and so on. During developement, we should probably "fake" this part and just log the email in the server console. I'll take care of introducing more robust mailing system.