Connected Account Providers Overhaul

[Foxtrek_64]

One of the weakest areas of XF currently, at least in my opinion, is with the Connected Account Providers feature. As it stands, if you use OAuth to allow users to authenticate with third party services, you can only have one of each service (which does make sense for some providers) and you are only allowed to use providers XF has specifically designated as available.

I know this list can be extended by third party development, but it still tends to be pretty locked down, only adding support for specific providers.

I would like to suggest an overhaul to this system with the following changes:

• Change the list of providers to a list of configured providers.
  • Add a button at the top to add a new provider, then like the create node button, prompt for which provider.
  • Allow configuring on the edit page - same behavior as creating a node
  • This allows for multiple providers to be configured, which is a benefit for some sites where they have a test/debug OAuth server and a live/prod OAuth server.
• List of providers
  • Apple
  • Facebook
  • Google
  • LinkedIn
  • Microsoft (O365)
  • X (Twitter)
  • Another Xenforo Community
  • WordPress (common request)
  • Other OAuth 2.0
  • MySQL Database
  • LDAP
• Add a "Generic OAuth2 Provider" option to the list of configured providers and prompt for the following information:
  • Provider name
  • Allow ACP logins
  • Allow front-end logins
  • What to do when someone signs in for the first time
    • Create an account
      • Flag for review
    • Reject (good for if you don't want people creating accounts this way)
  • Grant Type
    • Authorization Code
    • Implicit
    • Resource Owner Password Credentials (ROPC)
  • Client Identifier
  • Client Secret (for Authorization Code and ROPC)
  • Client Authentication Method
    • HTTP Basic (Recommended)
    • Client Secret
  • Scopes to request
  • Authorization Endpoint (for Authorization Code and Implicit)
  • Authorization Endpoint for ACP and Reauthorizations (for Authorization Code and Implicit)
    • Leave blank to use regular authorize endpoint
  • Token Endpoint
  • User Information Endpoint (for OIDC)
  • User ID parameter
  • Display Name parameter
  • Email Address parameter
  • Profile Photo parameter
  • Login button color
  • Login button text
  • Logo (image upload)
  • Show in account settings
    • Always (members will be able to associate their account if they haven't already
    • Only if their accounts are already associated
    • Never
  • When remote display name changes
    • Update local database
    • Allow the member to choose what happens
    • Do Nothing
  • When remote email address changes
    • Update local database
    • Allow the member to choose what happens
    • Do nothing

 

[MaximilianKohler]

A bit of feedback:

I tested out this feature recently and then disabled it.

1. It's barely even easier/quicker to register. Not really worth the hassle IMO.
2. The person would have to remember which option they chose to register with.

I do think that something of this nature is needed and useful so that people don't have to make a new account for every different forum, but I think a better implementation would be federation -- where people can post to your forum with an existing lemmy/mastodon, etc. account.

 

[Foxtrek_64]

A bit of feedback:

I tested out this feature recently and then disabled it.

1. It's barely even easier/quicker to register. Not really worth the hassle IMO.
2. The person would have to remember which option they chose to register with.

I do think that something of this nature is needed and useful so that people don't have to make a new account for every different forum, but I think a better implementation would be federation -- where people can post to your forum with an existing lemmy/mastodon, etc. account.

My use case may be a bit different than most, but it does get to something akin to federation.

In my case I use Zitadel to provide SSO across multiple communities. It's not quicker to register the first time, but when joining a subsequent community it's as fast as being logged into gmail and then logging in to YouTube. This also means there us no confusion about which provider someone used as it's always the same source (and if I had it my way I'd disable local author entirely).

That said, this suggestion is primarily for revamping existing functionality, though there are a couple of new proposals here. While I do agree that this can lead to poor UX, this is a common concern anywhere in a website where someone can design or customize any elements.

I don't personally find logging in with Facebook that convenient anywhere, but if a forum is a community around software development it may make sense to authenticate using GitHub or the lead developer's GitLab instance. Having the ability to add (theoretically) any relevant provider is the root of this suggestion but it would require an overhaul of the existing system.

 

[Kirby]

WordPress (common request)
MySQL Database
LDAP

Just curious:
How do you envision this to work?
WordPress (without Plugins) AFAIK does not have the capability to return user information about the logged in user to a 3rd party website.

And (My)SQL / LDAP are not websites at all - where would you want to direct users to when they click "Login via MySQL"?

I think a better implementation would be federation -- where people can post to your forum with an existing lemmy/mastodon, etc. account.

Choice is aways great, but I fear the vast majority of forum users doesn't even know about Mastodon, Lemmy, Fediverse, etc. so I don't think this would make much impact if it was available.

What (at least theoretically) could make an impact:
Login via Google and Apple - basically everyone has a Google or Apple account.

 

[Foxtrek_64]

Just curious:
How do you envision this to work?
WordPress (without Plugins) AFAIK does not have the capability to return user information about the logged in user to a 3rd party website.

And (My)SQL / LDAP are not websites at all - where would you want to direct users to when they click "Login via MySQL"?

WordPress would require some sort of OAuth2 compliant plugin to be installed. This would effectively be the same as the generic OAuth2 provider, but it would already know some of the details like the grant type and the scopes to request. In fact, all of the sites that use standard OAuth2 could be set up with the generic provider, but they'd be provided for convenience.

The MySQL is just a very bare-bones provider. Provide it with the credentials to access the database, the table to search, and the columns to identify the user. I think it would be more useful as a base for others to build on, but could be good for very simple deployments. I've personally never used this option where it's provided in Invision.

LDAP is not a website, true, but it is a standard authentication protocol useful for those running XenForo as an internal company website. This (combined with LDAPS) would allow for users to authenticate against an active directory solution. I don't see it used much outside of this scope.

 

[Kirby]

WordPress would require some sort of OAuth2 compliant plugin to be installed.

Thanks for the explanation, this makes your suggestion a bit more understandable now.
But I still do not fully get how you envision the WordPress provider to be different than Generic OAuth:
The grant type (most likely Authorization code), endpoints an scope(s) would depend on the WordPress Plugin so could be different for various Plg-ins.
So either the XenForo provider would have to support specific Plug-ins - or things like endpoints, grant type and scopes would have to be configurable - so where would that be different?

And I still do not understand how you expect SQL / LDAP proviiders to work.
All Connected Account providers basically work by redirecting the user to the target, target performs authentication / autorization (however that is done), user is directed back to XenForo and XenForo gets data from target (via API calls).

For pure LDAP / SQL there is no target website the user could be redirected to handle authorization.

So how do you expect this to work, do you want XenForo to ask the user for foreign credentials and validate them via LDAP/SQL?

 

[Foxtrek_64]

But I still do not fully get how you envision the WordPress provider to be different than Generic OAuth:
The grant type (most likely Authorization code), endpoints an scope(s) would depend on the WordPress Plugin so could be different for various Plg-ins.
So either the XenForo provider would have to support specific Plug-ins - or things like endpoints, grant type and scopes would have to be configurable - so where would that be different?

In practice, it probably wouldn't be. Same way as a Facebook or X/Twitter plugin wouldn't be different than Generic OAuth. The differences here would be that it would have a reduced number of fields for the user, since a lot of the answers are already known. But for the most part, all of the built in providers would end up using the same pathway as the generic oauth provider.

For Wordpress specifically, I imagine either it would not be directly supported (generic oauth only) or it would be designed to work with the most popular plugins.

And I still do not understand how you expect SQL / LDAP proviiders to work.
All Connected Account providers basically work by redirecting the user to the target, target performs authentication / autorization (however that is done), user is directed back to XenForo and XenForo gets data from target (via API calls).

For pure LDAP / SQL there is no target website the user could be redirected to handle authorization.

For the SQL provider, it just does what the standard login provider would do but refers to a different database/table than the standard XenForo database. I'm honestly not sure of when/why this would be useful as I've never used it myself, but someone may have an idea of how to use this.

As for LDAP, there wouldn't be any redirect. It would work similarly to XenForo's native login provider, but instead of consulting the database it would make an LDAP call to the configured server and either get a token or an access denied back.

So how do you expect this to work, do you want XenForo to ask the user for foreign credentials and validate them via LDAP/SQL?

Effectively yes.

 

[Foxtrek_64]

• User ID parameter
• Display Name parameter
• Email Address parameter
• Profile Photo parameter

A bit of clarification on these -

The User ID Parameter will always be required. This allows us to strongly associate a particular local user with the user identified by the foreign user id.

For the remaining parameters, these are all optional. If they are provided, then these values will be used when creating an account. If the provider is set to update the local database when foreign information changes, these values will also be used to overwrite local values whenever a user logs in. If they are left blank, then on account creation the user should be prompted for these values (just as they would if they were to register using XF's native account system) and the option to update the local database when foreign information changes would become a no-op.

Also, it appears that I cannot update my original post anymore, so I'll say here that I forgot to include a sign out field. When someone logs out of the forum, I expect that this should also trigger a log out of the external provider. Otherwise, you may see issues where the user clicks sign out, then upon navigating to another page or re-opening a link to the forum, they are suddenly signed back in.

 

[MaximilianKohler]

Choice is aways great, but I fear the vast majority of forum users doesn't even know about Mastodon, Lemmy, Fediverse, etc. so I don't think this would make much impact if it was available.

Maybe not now, but Threads joined the fediverse, Bluesky is federated but on its own protocol, Discourse forum software has joined/is joining the fediverse, and I believe Wordpress has an addon that allows federation. The fediverse is the future.

 

[Kirby]

When someone logs out of the forum, I expect that this should also trigger a log out of the external provider.

That might make sense for dedicated IdM solutions like Zitadal, Keycloak, etc. but probably not for the vast majority of non-dedicated connected accounts.
Think of users using Facebook, X, Github, Google, Apple, etc. as their IdP - I am pretty sure they would not want to be logged out of those services if they log out from a XenForo forum.
Apart from that logout with "plain OAuth" is not standardized in any way; support for OIDC Back-Channel Logout in conjunction with general OIDC support would indeed be nice though.

Otherwise, you may see issues where the user clicks sign out, then upon navigating to another page or re-opening a link to the forum, they are suddenly signed back in.

Won't happen. When you are log out of XenForo the sessions becomes a geust session it will not "magically" become a registered user session again due to a navigational request.
There is one exception though: A connected accout login link is accessed, in this case a new login is pferformed.[/QUOTE]

 

[Foxtrek_64]

Won't happen. When you are log out of XenForo the sessions becomes a geust session it will not "magically" become a registered user session again due to a navigational request.
There is one exception though: A connected accout login link is accessed, in this case a new login is pferformed.

I wanted to bring this up specifically because this is an issue on Invision Pro Board currently. Their implementation is not set up to handle this, and even though the issue has been brought up several times, it's always closed as "not a bug." I do have a feature request open with them but it's so far been ignored. There, if you click Log Out, you get sent to /signout. This completes the signout cycle then sends you back to the forum root. When your browser navigates there, it notes that you still have an active session with the third party provider and sends you to /signin and you're back to being logged in.

I am currently in the progress of migrating to XenForo, but not having the ability to log in with third party providers at all (save the ones explicitly configured by XenForo developers) has been a real pain point lately.

I use Zitadel to provide SSO across my communities, and while I could pay for bespoke development to add a Zitadel provider to the Connected Accounts feature, I feel like it'd be far more useful for everyone if the entire thing was reworked and the ability to add theoretically any OAuth2 provider was accounted for.

 

[MaximilianKohler]

Related: https://thenewstack.io/one-login-towards-a-single-fediverse-identity-on-activitypub/