Authentication RFC: Scope and options for user identification

[skinkade]

There are many ways to attempt to uniquely identify a user for them to log into
a system, all(?) of which flawed in some way.

This thread is for discussing the scope of what we would initially want to
support for user login, and perhaps the scope of what we might want to
eventually support.

Forms of login ID

Below are forms of identification, with their strengths, weaknesses, and other
considerations. Most of this is common knowledge, but just to lay it out:

Username

Pros:

• Good for privacy, if no email/phone requirement

Cons:

• High spam probability without email/phone verification

Other:

• It's common for a username to be a (possibly changeable) display name "in
  front of" email or phone
• A user may want to change their display name

Email

Pros:

• Extremely common
• Very common ID method (UX expectations)
• If we have a user's email, we can use it to send them MFA codes
• Major email providers try pretty hard to verify new(er) accounts via SMS

Cons:

• Reliance on third-party for sending emails
  • (However, we want to support this anyway)
• There are a number of "15-minute email" type services for temporary emails,
  meaning they aren't especially reliable in terms of preventing spam accounts
  and the like, unless we present the option to limit sign-ins to major
  providers

Other:

• A user may want to change the email address they have associated with their
  account

Phone / SMS

Pros:

• Extremely common
• Fairly common method for primary ID, especially for mobile apps
• Very common method for verifying accounts
• Can also be used for MFA codes
• Harder to obtain than an email -> less spam from verified accounts(?)

Cons:

• Requires a third-party to send
• Users are generally more hesitant to give out their phone numbers than their
  emails

Other:

• A user may want to change the phone number they have associated with their
  account

Social Login

Pros:

• No additional password required
• Convenient for users

Cons:

• Higher implementation complexity

Other:

• This gets a little tricky for systems that support both email-based and social
  logins. If I have me@gmail.com signed in via email+password, and then decide
  to login in via OAuth, what happens?
  • Is it the same account, i.e. a "merge"?
  • Is it a different account, where there's a identity provider field
    distinguishing it?

Canonical ID

I think we should use UUID v4s for canonical user IDs, making usernames, emails,
and perhaps phone numbers optional fields, where the application author can
determine which is the default / primary means of identifying a user. All
user-associated records would of course be linked with the canonical UUID, so
the application author would be able to have a more "open" system if they so
choose. This allows for perhaps the changing of associated username / email /
phone number without affecting very much apart from the user's login means.

The database performance concerns of random UUIDs aren't worth worrying about
until you get to a very large number of user accounts, from what I can tell.

Initial Scope

A basic yet flexible start would be to target scenarios such as:

• Email as login ID
• Username as login ID, with (optional?) account verification via email
• Username or email as login ID
  • (If input contains @ try email lookup, else try username lookup)

Username here, if available, would be the display name of the account. MFA codes
can be sent via email, if enabled for the account and email sending configured
for the application.

Eventual Scope

I consider social logins to be highly desirable, but this would require more
R&D. We'd need separate modules per provider, most likely, and likely some form
of additional distinguishing detail in the model / schema.

I would consider SMS-based login IDs to be low priority, and SMS-based account
verification to be slightly higher priority, but lower than social logins.

[isaacharrisholt]

unless we present the option to limit sign-ins to major
providers

This would be the concern of the application developer, not Pevensie.

This gets a little tricky for systems that support both email-based and social
logins. If I have me@gmail.com signed in via email+password, and then decide
to login in via OAuth, what happens?

• Is it the same account, i.e. a "merge"?
• Is it a different account, where there's a identity provider field
  distinguishing it?

We can potentially provide both options, though I would be inclined to go for the first option by default. Supabase do this well.

I think we should use UUID v4s for canonical user IDs

UUIDv7 would be preferable, I think.

Username or email as login ID
(If input contains @ try email lookup, else try username lookup)

This is not a Pevensie concern - we would provide functions for email signin or username signin, and the application developer could write this logic. That said, we might not want username signin as an option, as it's trivial to implement on top of email.

Imo we should start with email+password auth, as it's the simplest. We can integrate it well with the email package when we create it later.

[skinkade]

This would be the concern of the application developer, not Pevensie.

👍

We can potentially provide both options, though I would be inclined to go for the first option by default. Supabase do this well.

I think that's a reasonable default, personally.

UUIDv7 would be preferable, I think.

If we can be reasonably certain that the user's canonical ID is never externally shown, then v7 would be better for performance. However, if it could be shown anywhere client-side (including in URLs), then it would leak account creation time.

... we might not want username signin as an option, as it's trivial to implement on top of email.
Imo we should start with email+password auth, as it's the simplest. We can integrate it well with the email package when we create it later.

Agreed. We can always start with email + password, where there's implicit verification via sending them a registration confirmation link via email. Usernames can come later to fulfill purposes like display names.

[isaacharrisholt]

it would leak account creation time

We can never be certain of anything given we're building something for devs, though it's worth considering for sure. I doubt there are other sortable options that don't have this issue. Also, how big a deal is this?

[skinkade]

Partly in response to Nicd in Discord with regards to SMS' relative insecurity for MFA:

I mentioned sending MFA codes via email / SMS because it does provide some degree of additional security while having a fairly decent UX. Especially if we're starting with email-based authentication, then an application can potentially default to email-based MFA (this is quite common, in my experience).

Both email and SMS based MFA are less secure than OTP, which we should also support in time, but that may be worth a separate discussion.

[garthtrickett]

https://lucia-auth.com/ is the best auth library I've seen in any language. Worth having a look for some inspiration.

[lpil]

A con for SMS: it's not exclusively usable in a B2B context due to employees not all having company phone numbers.

[isaacharrisholt]

Agreed if it's the only option, we can offer it and leave it up to the application developer to make the best choice for them

[garthtrickett]

Oidc on 0auth with it setup so adding in the biggest providers is easy then an email option that sends a code to users email rather than a password for the people that don't like using sign in as google.

[naomieow]

Passkey support would be amazing to have as well!

[isaacharrisholt]

I agree. I'd ideally like to have it. We should sit down and try and map things out before we just go ahead and build them.