Please Comment: Auth library

[Arlen22]

I need recommendations for an auth library.

I did see Auth.js, which I don't know much about.

Hopefully some of you can weigh in on this.

[MagicJF]

This summarizes some open source auth alternatives:
https://youtu.be/lxslnp-ZEMw?feature=shared&t=1h2m30s

[linonetwo]

Sorry for late reply, I recommend using DID for auth, see this demo https://service.agent-network-protocol.com/wba/examples/

There is no username and password, it uses public/private key pair, like how BTC creates account. This is supported by W3C and Bitwarden (both are opensourced)

This is the future of account system, no need for password, more secure and convenient.

If you think DID is too new, you can also consider passportjs as I used in https://github.com/linonetwo/try-passportjs-gitlab-tiddlywiki

[Arlen22]

The problem with passwords isn't that we don't have viable alternatives that we could implement, it's that passwords are the least confusing way for a user to log in. The second least confusing way to log in is, you guessed it, logging into someone else's site with a password, and then logging into your site by clicking a button that says "Login with ___"!

[ppetru]

Weighing only on the secondary point here: being able to integrate with an OAuth provider would be particularly useful in a MWS world of multiple wikis/users/etc. Auth.js looks like a reasonable way of doing that, but I'm not familiar with the ecosystem of alternatives.

[ppetru]

To be more specific, after having played a bit with MWS: ideally, it should support getting all the information it needs (username and roles) from the SSO system via OAuth, so that it doesn't need an user database of its own at all in that configuration.

[Arlen22]

To be more specific, after having played a bit with MWS: ideally, it should support getting all the information it needs (username and roles) from the SSO system via OAuth, so that it doesn't need an user database of its own at all in that configuration.

Interesting. I think that would be doable. Roles are used for ACL access, and user ids are used to record ownership as well as a few other things. An ACL check should be able to get by with the numeric user_id and a list of role_ids. We would need that available for every request.

• An auth adaptor could, for example, pull the user_id and groups (roles) from the id token and match them to the ACL.
• If a group gets renamed in the SSO system, the ACL table would be outdated, but that should be obvious to anyone with auth experience.
• The adaptor would need to provide the list of role ids and descriptions (cognito groups) to the ACL editor so users can add ACL entries.
• Pretty much the only place we need to provide a list of users would be for admins to change ownership of items, but we could let the auth adaptor decide whether to have that be a text field or a select dropdown.
• Another optional feature would be to get the display name of a single user or a list of users so we can see who owns what without having to copy and paste their user_id into the other system.
• We should also have some profile information for the user, which I'm assuming is usually in the idToken.

Overall I think that would actually be fairly doable. The user and role tables could be isolated from the other tables so the default auth adaptor could still use them but it would just pull the role_ids at the start of the request and then the ACL checks could just use that list of ids instead of doing a join.

[dxcSithLord]

You could also consider grc.com/sqrl - developed by Steve Gibson at grc.com, and he made it opensource (free to use for anyone). Software is available on github. Information available also at sqrl.grc.com. No passwords are used, or stored, in the access of websites, only a public key unique to the user and the website. After login, any information shared is between the user and the website.

From the "What is sqrl?":

SQRL Logs Into Websites For You

Instead of using a username, email and a password, SQRL uses an app to login to SQRL-aware websites.

When SQRL logs you into a website, your identity is a long code that looks like this: E6Qs2gX7W-Pwi9Y3KAmbkuYjLSWXCtKyBcymWloHAuo.

Your SQRL identity is a different long code for every website you login to, but it is always the same code when you return to a site you visited before. This means that websites never know who you are, but they do know when you return.

You may choose to remain anonymous to a website, such as when you post a response to someone's blog. SQRL never identifies you by anything other than that long code.

In other cases you will want to be known, like when you use SQRL to login as you at Amazon, Facebook, Netflix, or your bank. In those cases, you would inform Amazon that that particular code is actually you. SQRL lets you do that.

The SQRL system took 5 years to develop. It is now complete and you are invited to browse around these SQRL forums to learn more. You can obtain SQRL apps and experiment with using them to logon to a growing number of websites. We believe that SQRL is the future of Internet website identity authentication. We hope you will agree.

We suggest you read the brief Introductory Q&A page next.