Auth improvements

[emrosenf]

Running list

Email / Password

• Error messages (or different error codes) that differentiate between "incorrect password" and "no EmailFactor with this email exists"

WebAuthn

• Allow adding a nickname to the WebAuthnFactor like "Apple iCloud" or "Google Chrome". This will make it easier to help users manage various factors.

General

• Make the __type__.name of the currently used Factor accessible from the session (i.e. stored in the token). This useful in a 2FA situation so we can easily tell if the user is logged in with the second factor vs email/password.

[scotttrinh]

Good feedback, I'll address some of this directly. Ultimately once you have a list that feels like it encompasses most of your feedback, we can split these out into separate issues based on what we decide.

I'm going to make this a discussion to keep the issue tracker focused on fully scoped issues and bug reports.

[emrosenf]

@scotttrinh Thanks for the thoughtful feedback. Do you see user impersonation as application-domain or edgedb-domain?

[scotttrinh]

Error messages (or different error codes) that differentiate between "incorrect password" and "no EmailFactor with this email exists"

We don't want to leak the existence of an existing email directly to the end user and these endpoints are "public" endpoints so an attacker could make requests directly to the various endpoints to enumerate emails. However, we might consider putting the auth endpoints behind (server) authentication just like the other extension endpoints since the primary use case here is making requests from your server not being directly addressed by clients. Once we've done that, we would consider allowing developers to opt-into more detailed error messages that might leak sensitive data for authenticated requests. Good feedback!

[scotttrinh]

Allow adding a nickname to the WebAuthnFactor like "Apple iCloud" or "Google Chrome". This will make it easier to help users manage various factors.

Things like this are (at least at the moment) fully in the domain of the application, and I don't see us wanting to own more of the application's domain data in the schema itself. The main reason is that if the auth extension schema owns it, it's harder to change things to address your specific requirements. We'd need to make this optional, but you might want to make it required in your application and then you'd have to defend against a value you don't intend on being optional.

My suggestion for this specific case is to add a WebAuthnFactor type to your application schema like:

type WebAuthnFactor {
  required factor: ext::auth::WebAuthnFactor;
  required label: str {
    constraint exclusive;
  };
  # any other metadata you might want to capture here
}

You could even make the type more generic like:

type MultiFactor {
  required factor: ext::auth::Factor;
  required label: str {
    constraint exclusive;
  };
  # other metadata
}

To account for future multi-factors like TOTP, recovery codes, etc.

[scotttrinh]

Make the type.name of the currently used Factor accessible from the session (i.e. stored in the token). This useful in a 2FA situation so we can easily tell if the user is logged in with the second factor vs email/password.

This is a great idea! We don't currently consider the JWT to be public API, so I don't think we'd want to start encouraging application developers to parse the tokens themselves, but we can consider ways to expose details about the authentication back to the application more directly. Maybe in the payload along side the token, or maybe even in the PKCE code exchange to avoid needing to even get the token if you're just doing a second/multi factor check rather than a reauthentication.

In the meantime, you can get this information in an extra query by looking at the factor that is associated with the identity.

select ext::auth::Factor {
  factor_name := .__type__.name,
} filter .identity = global ext::auth::ClientTokenIdentity;