Accounts improvement initiative

community
1

Primarily based on this discussion: Accounts improvements suggestions 👥 · meteor/meteor · Discussion #11653 · GitHub
But more broadly on all the discussions around accounts: meteor/meteor · Discussions · GitHub

I’m starting the accounts improvements initiative to add new features and improve Accounts by Meteor Impact and beyond. Accounts is one of the top rated MeteorJS feature, but it hasn’t been getting the love lately that it deserves.

BetterAuth has been getting a lot of attention lately, not to mention many of the Auth SaaS.
Recently we had the addition of Roles which is a move in the correct direction, but we need a lot more. I’m looking for help in implementing the following (into core - open to discussion):

Add new important OAuth to core:

  • Apple (probably best if one of the )
  • GitLab (just a suggestion, LinkedIn is another good candidate)
    Further extend documentation and list community OAuth solutions to other popular services. Best to look at what competitors have and what we should have so that when decision makers look at our list of official providers it will be attractive to them (which is why I believe that Apple is a must, plus Apple rules that make it mandatory if you have OAuth).

OAuth in general:

Additional 2FA options:

  • Backup codes
  • Passkey / Webauthn
  • One Tap
  • Security challenge - a method to trigger 2FA challenge before proceeding with an action (for example access to billing information or changing critical business information)

Roles:

  • More docs
  • Ability to define admin role and who should it have assigned by default
  • Based on scopes create an organizations package that would allow creation of organizations and managing of scopes for users of the organizations. It should have a robust inviting functionality to handle inviting inside an app and also to send out emails that would create a user when accepted. Build on top of enrollment functionality.

Further work:

Obviously I can’t manage all of that on my own, so I’m looking for help.
The goal is to get as much done as possible by Impact, so for me I will work on this a bit more during August.

So any takers?

4 Likes
2

Another issue I reported: Accounts: findUserByEmail is only present when accounts-password is added · Issue #13834 · meteor/meteor · GitHub

Additionally I have trouble getting the email template for passwordless translated. Would open a PR for both.

Regarding PKCE I would go for a package to keep it optional.

What I currently rather like to know: how important is CSRF prevention in Meteor accounts?

1 Like
3

I myself am most interested in impersonation (though I know that @xet7 already has a solution in Wekan, so that might be a good starting point) and security challenge.
Recently I had issues with Facebook and Google OAuth and on Brave browser in general, so I will try to look into fixing bugs in those solutions and I think we should consider the end of popup experience which looks a bit hacky to me and I think we can look into more modern solutions here.

What I see myself doing to get to impersonation:

  1. Accounts.logoutAllSessions and Accounts.logoutNonCurrentSessions this would logout and remove all sessions for the given user (the second without removing the current user session - so only usable by the user themselves). There should be a hook (or after step 3 admin check especially for the first one) to check that only the user themselves or admin can trigger this function. PR
  2. Accounts logging package - a package that will log events like user login and logout into a separate collection user-audit, this will also later include impersonation by admin and can be potentially used for other user related action. Can be skipped, but good to have or we could have just impersonation logs instead.
  3. Global admin role - a setting for the roles package to create a global admin role on startup and assign a default user to it (or determine that the first registered user should be admin. - something to discuss
  4. Impersonation package - first only admin or users that pass a custom check can trigger the impersonation method Accounts.impersonate(userId). If admin then it would create a new session for the target user that the admin would use to operate on behalf of the target user. Session storage would be used to store the original admin session. Then there would be Accounts.stopImpersonation that would destroy the session that the admin uses and return admin back to their original user. The limit of impersonation would be 1 hour (configurable default).
  5. UI - For Blaze I would expand accounts UI package or create a new one. The idea is to have an UI that would show which user you are currently impersonating and the stop impersonation button. Maybe even some option to start the impersonation. With this would come an example to showcase the capabilities (probably derivative of the todo app) and a reference React implementation.
  6. Security challenge package - with this also add the security challenge as required to impersonation start

How does that sound?

4

Related WeKan info:

5

Here are also all open (including a few older) PRs that need merge/review/improvement/update/needs to be closed; sorted from oldest to newest:

1 Like
6

As my two cents, the package pwix:startup-app-admin defines the APP_ADMINISTRATOR role and assigns it to the first created user who makes his email address verified.
My own estimation is that the implementation is a bit clumsy, and I’m not very happy with it, but it works and does the job.
Best regards