Oauth 2/OpenID

[Gytis]

Are you implying that your users would login/register via an existing OAuth2 provider? Or are you looking for the forum itself to provide an OAuth2 server?

If the former, we have an "external auth" framework which we use for the "Login with Facebook|Twitter|Google" feature that we have. This is fairly easy to extend to add new providers but that would require additional development.

Is it possible to add "custom" provider? Any tips or guides how to do that?

I do have couple OAuth servers (providers) that I would like to try out with XenForo.

 

[Chris D]

It's quite a big system that is quite faceted so I don't really have any guides that go through it in any detail.

But a few pointers...

There are three types of classes which make up the bulk of our OAuth interactions.

Provider​

Example: src/XF/ConnectedAccount/Provider/Linkedin.php

This sets up the options that we need to pass into the Service such as the API keys, scopes and where to redirect to once the user has authenticated and points to various other classes such as the OAuth Service class, ProviderData class etc.

ProviderData​

Example: src/XF/ConnectedAccout/ProviderData/Linkedin.php

This defines how we can retrieve the data that we need from the Service. At minimum we need the "provider key" which is the identifier that uniquely identifies the account, but you can optionally use it to get a name, email address etc. which can be used to pre-populate certain fields on registration.

Service​

Example: src/XF/ConnectedAccount/Service/Linkedin.php

The Service is the class that sets up most of the heavy lifting in order to communicate with the OAuth server provided by a service such as Linkedin, Facebook, etc. Most service classes actually ship with the OAuth client library which is why you won't see many listed in the src/XF/ConnectedAccount/Service directory. I've used Linkedin throughout this post because this is one example where we do actually implement the client service in full on our own.

This defines things like the API URL, authorization endpoint, access token endpoint, and sets up various parameters that might need to be passed into the HTTP client. Crucially it includes a way to parse the access token response.

There is a few more things to do within XF itself in order to make use of these classes, but if you can populate the above classes for your OAuth provider you're about 90% of the way there.

Other things to do are:

• Add your provider class to the xf_connected_account_provider database table
• Create an admin template e.g. connected_account_provider_linkedin containing the fields required to configure the provider (particularly with API keys etc.)
• Create another admin template e.g. connected_account_provider_test_linkedin which is the template displayed when you "Test provider" in the Admin CP
• Create a public template e.g. connected_account_associated_linkedin which is the content displayed when a user has associated with that provider.
• Finally you might need some CSS for the button/icon on the register/login pages, and some phrases.

Hope that helps.

Follow the XF code as much as possible, particularly the Linkedin example, and you should be ok.

 

[robdog]

You can definitely add custom providers. As Chris said, look through the provided ones. You should be able to gather enough details to build out the custom solution. I have added 3 custom providers and it is pretty straight forward and easy.

 

[BubbaLovesCheese]

Hi,

I was wondering if there is a way to automatically register a new user through the Connected Accounts Providers, without having the manual step that leads to this registration screen.

Is there a way to automatically avoid it?

Thanks.

 

[DevOops]

It's quite a big system that is quite faceted so I don't really have any guides that go through it in any detail.

But a few pointers...

There are three types of classes which make up the bulk of our OAuth interactions.

Provider​

Example: src/XF/ConnectedAccount/Provider/Linkedin.php

This sets up the options that we need to pass into the Service such as the API keys, scopes and where to redirect to once the user has authenticated and points to various other classes such as the OAuth Service class, ProviderData class etc.

ProviderData​

Example: src/XF/ConnectedAccout/ProviderData/Linkedin.php

This defines how we can retrieve the data that we need from the Service. At minimum we need the "provider key" which is the identifier that uniquely identifies the account, but you can optionally use it to get a name, email address etc. which can be used to pre-populate certain fields on registration.

Service​

Example: src/XF/ConnectedAccount/Service/Linkedin.php

The Service is the class that sets up most of the heavy lifting in order to communicate with the OAuth server provided by a service such as Linkedin, Facebook, etc. Most service classes actually ship with the OAuth client library which is why you won't see many listed in the src/XF/ConnectedAccount/Service directory. I've used Linkedin throughout this post because this is one example where we do actually implement the client service in full on our own.

This defines things like the API URL, authorization endpoint, access token endpoint, and sets up various parameters that might need to be passed into the HTTP client. Crucially it includes a way to parse the access token response.

There is a few more things to do within XF itself in order to make use of these classes, but if you can populate the above classes for your OAuth provider you're about 90% of the way there.

Other things to do are:

• Add your provider class to the xf_connected_account_provider database table
• Create an admin template e.g. connected_account_provider_linkedin containing the fields required to configure the provider (particularly with API keys etc.)
• Create another admin template e.g. connected_account_provider_test_linkedin which is the template displayed when you "Test provider" in the Admin CP
• Create a public template e.g. connected_account_associated_linkedin which is the content displayed when a user has associated with that provider.
• Finally you might need some CSS for the button/icon on the register/login pages, and some phrases.

Hope that helps.

Follow the XF code as much as possible, particularly the Linkedin example, and you should be ok.

If I added Ory as a custom provider, then would you recommend roughly following OAuth2?

 

[DevOops]

Nearly one year later...

Hi,

I was wondering if there is a way to automatically register a new user through the Connected Accounts Providers, without having the manual step that leads to this registration screen.

Is there a way to automatically avoid it?

Thanks.



View attachment 235750

Are paying customers like this ever going to get replies?