Possible authentication methods with a new type of login

[janko]

I'm close to releasing an OmniAuth integration for Rodauth. When the user logs in via an OmniAuth strategy, the session is considered authenticated by "omniauth". Additionally, "omniauth" is added to possible_authentication_methods if there is at least one connected provider. I mimicked the implementation from the email auth feature:

def possible_authentication_methods
  methods = super
  methods << "omniauth" if !methods.include?("password") && omniauth_connected_providers.any?
  methods
end

However, I quickly realized that this doesn't work well when both email auth and two factor base features are enabled, because as soon as the user connects an external provider, possible_authentication_methods returns ["email_auth", "omniauth"], which causes uses_two_factor_authentication? to return true. In the Rails demo app, I have the following code in the Roda's route block, which then triggers a request for multifactor authentication:

if rodauth.uses_two_factor_authentication?
  rodauth.require_two_factor_authenticated
end

How do I correctly deal with this scenario? If I also check that !methods.include?("email_auth"), that will work only when omniauth feature is enabled after email auth, but not the other way around.

[jeremyevans]

I think the best fix would be not allowing email auth for accounts with omniauth connected providers:

# in omniauth feature
def allow_email_auth?
  (defined?(super) ? super : true) && omniauth_connected_providers.empty?
end

This works because email_auth uses defined?(super) ? super : true for this method. I think it makes sense, because omniauth should no be allowed for accounts that have passwords or accounts that allow email authentication. The whole point of omniauth is your are outsourcing the authentication part to a 3rd party.

[janko]

Thanks a lot, that works! 👍🏻

[janko]

I think I noticed one more place where authenticated_by logic also needs to handle the new authentication type, which is the confirm_password dialog. Currently, I think the following scenario could happen:

1. user authenticates via OmniAuth (authenticated_by is set to ["omniauth"])
2. user confirms their password on a sensitive action (authenticated_by is set to ["omniauth", "password"])
3. the user is now considered two-factor authenticated

This is because confirm_password feature explicitly enumerates all 1st factor authentication methods, which excludes any new ones like omniauth. What would be the way to handle this correctly? Should password confirmation be stored in a separate session key? I see that it's stored in authenticated_by to be usable as 2nd factor with webauthn passwordless login.

[jeremyevans]

I'm not sure why ["omniauth", "password"] shouldn't be considered two factor authenticated by default, since it is two separate factors. If you don't want that behavior, maybe override two_factor_authenticated to do super && authenticated_by.sort != ["omniauth", "password"]?

[janko]

That's an interesting point, I haven't considered that 2nd factor can be something other than the designated 2nd factor authentication methods. You're right, this does sound like good default behaviour to me now.

This got me thinking about email authentication, could that also be considered 2nd factor together with password authentication? What I mean is, when the user logs in via an email auth link, and confirms their password, can that be considered two factors (if we view the email account as something the user owns)? Currently, password confirmation removes email auth from authenticated by list.

[jeremyevans]

The password/email_auth being treated as single factor is deliberate, because if you have access to email, you can reset the password, so it's really only single factor if you are allowing password resets (which I assume most users are). I don't think that is the case for omniauth and password, unless the omniauth email is the email that password reset links would be sent to.

[janko]

Oh, that's right, makes total sense. Yeah, even if OmniAuth email is the same, an attacker might just have access to the 3rd party account, but not necessarily to the email account.

I could imagine that a password breach might be problematic if people reuse their passwords; when OmniAuth & confirm_password are enabled, an attacker could use the same breached password on the main app and the social login for those accounts, thus fulfilling both factors. Even though the user might have configured a stronger 2nd factor, the developer might have inadvertently allowed authenticating with a weaker alternative 2nd factor (social login).

Your suggestion for how this can disallowed in an app works, it would just be nice to be able to disable it within the rodauth-omniauth gem. I will think about it if there is some simple change that could be made to enable this.

[janko]

It was very easy 🤘🏻

    def before_confirm_password
      authenticated_by.delete("omniauth")
      super if defined?(super)
    end