XF 2.2 Best way to handle forced login via connected account?

[SpecialK]

We are migrating a forum from vBulletin 4. In this installation, users were forced to log in via a third party API (The vBulletin login process was hijacked by our plugin, to authenticate the submitted user/pass combination with the third party, then starting the vBulletin session if the auth was successful).

In XF, we have upgraded this third party integration to work with OAuth and XF Connected Accounts. This new OAuth integration is working fine.

Now here is the problem: The users MUST be forced to log in via our custom OAuth provider. They cannot be allowed to log in via XF user/pass combination. We have this part working fine. The problem that arises is that in order to connect a third party account, the user must first be logged in to XF. Otherwise, they will receive an error response upon attempting to log in - The email address linked to this {Provider} account belongs to another member's account on {Site}. Please log into that {Site} account to associate with {Provider}.

So I'm looking for some bright ideas on how we can handle this. Should we simply override that error and allow the connected account process to complete, or should we deal with this in some other way? The key here is that users don't even know their XF passwords, because in the database, it's stored as a random string. And allowing the users to log in via XF Auth completely bypasses the connected account login, which is no good. They must only be able to log in via our single OAuth provider.

Hoping someone has a bright idea on how to seamlessly get this implemented.

 

[mattrogowski]

Our free (with the coupon code) Connected Account Provider addon handles this: https://www.themehouse.com/xenforo/2/addons/connected-account-providers

It has options to force a connected account login:

 

[SpecialK]

We've already coded the Force OAuth registration and Force OAuth login features into our provider. The question is how to connect an account to an existing XF account without knowing that XF account's password - Does your add-on implement that functionality?

 

[mattrogowski]

Oh, I see what you mean - I don't think you'd be able to do that, the user has to either register with the provider, or be logged into their XF account to connect it after the fact. If you were to log in via the provider and XF finds an email match with a user, it says you need to log in to the XF user to connect it (I missed that your post mentioned that). The only way I can think to do what you need is for them to reset their passwords, connect their XF account with the provider, and then the connected account provider login would be used thereafter.

 

[SpecialK]

Right - That's the entire question - How best to implement this flow. I've been wracking my brain trying to think of a smooth process that's not overly complicated, and the best thing I came up with is to:

1. Remove all View/Post permissions from Registered Users group
2. Create new "Connected Account Authenticated" usergroup
3. Create XF promotion to promote user to that group after they've connected
4. Write a small snippet of code that hijacks the login process, and if the user belongs to that new group (Meaning they've already connected their account), stop the login and redirect to the 2FA login process.

In this way, we're only writing custom code for #4 - #1-3 are taken care of with core XF functionality. But I was hoping to come up with something simpler.

 

[mattrogowski]

Not knowing what the provider is, you could try manually importing the data - there will be a row in xf_user_connected_account where provider_key is the remote user ID, but I don't know if you'd need tokens stored in extra_data. Then there's also cached provider data in the connected_accounts column in xf_user_profile. It's kinda hacky but might be worth trying to see if it works.

Or, as you said, allow the connection to be made when XF finds an existing XF user, so long as that's not going to be open to abuse/account hijacking (which I guess is why XF has that check in the first place).

 

[SpecialK]

In this particular case, hijacking is not a concern. There is only going to be ONE Oauth provider, and the users can only log in via that provider if they have a paid membership on that side of things. I may look into that and see how easily we can bypass that check.

 

[SpecialK]

@mattrogowski Just as an FYI - I took a look at the TH Connected Accounts provider, and it actually already does EXACTLY what we were talking about above. There is an option to allow users to associate the connected account with an already-existing XF account. And it works perfectly. I'm not sure if this got added after our discussion or if you simply weren't aware of its existence, but yeah, it works great.

 

[mattrogowski]

@mattrogowski Just as an FYI - I took a look at the TH Connected Accounts provider, and it actually already does EXACTLY what we were talking about above. There is an option to allow users to associate the connected account with an already-existing XF account. And it works perfectly. I'm not sure if this got added after our discussion or if you simply weren't aware of its existence, but yeah, it works great.

Huh, I'm not gonna lie I didn't know that existed, but I'm glad you noticed it and that it resolves your issue!