XF 2.3 Single sign on and more with OAuth2 in XenForo 2.3

We're approaching the conclusion of the 'Have you seen...?' series for XenForo 2.3. While it may seem like a bittersweet moment, we've intentionally saved one of the most exciting revelations until last. In the upcoming weeks, we might delve into a few more miscellaneous changes and improvements and provide a more developer-centric round up. However, our primary goal is to have XenForo 2.3 up and running on XenForo.com by the end of November. Beyond that milestone, we're excited to share a couple more surprises with you, which will include an overview of the latest enhancements in XenForo Resource Manager, Enhanced Search, and Media Gallery 2.3.

But, back to today, and not only is this an exciting revelation, but it also signals the implementation of our most popular suggestion of all time. Your XenForo installation will be able to act as an OAuth2 server and this opens up a whole array of advanced use cases:

• Single sign on between your forum and another XenForo installation
• Single sign on between your forum and another software
• Building a different front end for your forum, such as a single page app
• Building a native smartphone app for your forum
• Integration between your forum and another application
• Accessing the XenForo REST API as a specific user with a OAuth token

As ever, let's take a look at how to set this up in XenForo 2.3. In the following example we're going to configure an OAuth2 client on a primary XenForo instance and use a secondary XenForo instance to use that primary instance as a connected account provider.

You can add as many OAuth2 clients as you need and this can be done from your admin control panel under Setup > OAuth2 clients (which lists all clients you have created) and clicking "Add OAuth2 client".

And this is what it looks like all filled in:

Most of this is self explanatory. Title, Description, Homepage URL and Image URL are used for branding any OAuth authorization page. Let's take a closer look at a couple of other inputs on ths page.

Client type​

The difference between "Public" and "Confidential" client types may not be immediately obvious but it is crucial. For the sheer majority of OAuth integrations you might have experience with in the past, you are most likely more familiar with the default option which is the "Confidential" type.

For most applications the "Confidential" type is fine. This means you're able to keep the client secret confidential - in other words, the client secret isn't stored or revealed anywhere by the client. This would be appropriate for a XenForo to XenForo connected account.

For situations where it's not safe to store a secret in the client application (like in JavaScript, single-page apps, or native apps), you should choose the 'Public' client type. When using the 'Public' type, you employ the Proof Key for Code Exchange (PKCE) authorization flow. Instead of sharing a secret, you create a random string. This random string serves as a secure way to confirm your identity during the authorization and token exchange process.

It should be noted that PKCE is required for public clients and recommended for confidential clients. A deeper dive into PKCE is beyond the scope of this post, but rest assured everything will be documented via the manual and/or developer documentation before XenForo 2.3 is released.

Authorization / Token / Revocation endpoints​

These are simply the endpoints you need to communicate with in order to authorize, retrieve a token and revoke tokens as per the OAuth 2.0 specs.

Redirect URIs​

Here you can add one or more redirect URIs. These are the approved redirect URIs that the secondary instance may use. Occasionally you might need more than one redirect URI to support different domains or different endpoints that may get called as part of the process. In this example, as we're going to be communicating from a second XenForo forum, its connected_account.php is sufficient as a redirect URI.


Once the client is created you will be able to view your credentials:

Armed with these, we can now set up a connected account provider on the secondary XenForo instance.

The connected account side of things is all very familiar if you've ever set up any of the existing ones before. The crucial thing is to make sure you get the target board URL correct.

But what you really want to see is the authorization process, don't you?

Via the login, registration or Account > Connected accounts page, as soon as you click the button that corresponds to your new XenForo connected account provider, you will be redirected to the authorization page:

Clicking Authorize will complete the usual steps to authenticate you using OAuth and redirect you back:

If you have approved any applications to access your XenForo account then you can see a list of them under Account > Applications:

While exciting in itself, this is merely a single use case amongst many that our OAuth implementation will open up. And this is where we will leave it for this week. Next week we'll be focusing an entire 'Have you seen...?' entry on what's new for developers in XenForo 2.3. This will enable us to provide a more detailed dive into some smaller, developer-centric changes, including a closer look at some more advanced parts of OAuth such PKCE, authenticating against the REST API and refresh tokens.

If developers want us to talk about anything specific in more detail that we might have mentioned in the last few weeks, please do let us know.

 

[LuckyRiver]

Using Authorization code, do I still need to activate view permission for guests/unregistered users group?
I have to do that when using bdAPI Oauth2 Authorization code, otherwise I receive an error that I must logon.
It happens right after I receive the authorization code to ask for a token.
It will be great if it works without having to activate the guest view which most private sites do is to force members to login to view.
But somehow it needs view permission for unregistered users needs to be activated for Oauth2 to work.

 

[KaiKimera]

One of my most anticipated features. A similar function is available in IPS and MediaWiki (Wiki-farm).

 

[jauburn]

Once XenForo 2.3 is out I will look into making the changes needed to support oAuth.

Will Xenforo be able to integrate with WordPress natively, without a plugin?

 

[Kirby]

Will Xenforo be able to integrate with WordPress natively, without a plugin?

Most certainly not.

I might be missing smth, but:
Where can API scopes for OAuth2 clients be configured?

Quickly looking at the code it seems that a client with a valid token can make just any API call.
If that is really the case that would be quite a bummer (to me) - we use the API for internal things and allowing any OAuth authenticated user access to al APIs is certainly a no-go.

It also seems that XenForo 2.3 still uses a really outdated OAuth client library - this is kinda disappointing

 

[snoopy5]

Will Xenforo be able to integrate with WordPress natively, without a plugin?

I have the same question. I would like to use XF 2.3 as a "master" where all users have to register. Then the XF users shall be able to post comments or give ratings in a wordpress installation of the same domainname (no subdomain).

Will this be possible with XF2.3 and if yes how exactly?

 

[James]

I have the same question. I would like to use XF 2.3 as a "master" where all users have to register. Then the XF users shall be able to post comments or give ratings in a wordpress installation of the same domainname (no subdomain).

Will this be possible with XF2.3 and if yes how exactly?

I would like to think that upon completion of XF2.3 stable that one of the devs would do a miniseries on the power of the webhooks and a few "real-world" examples of integration so that they can be utilised outside of the "technically capable" group of admins.

I'm sure a whole bunch of devs will release tutorials or guides or even addons that would do this (are webhooks exportable for direct upload/install?)

Would be curious if this (is/could be) being considered by the team ? @Chris D @Paul B @Jeremy P

 

[Chris D]

Client scope restrictions are still planned for prior to a stable release.

 

[snoopy5]

I would like to think that upon completion of XF2.3 stable that one of the devs would do a miniseries on the power of the webhooks and a few "real-world" examples of integration so that they can be utilised outside of the "technically capable" group of admins.

I'm sure a whole bunch of devs will release tutorials or guides or even addons that would do this (are webhooks exportable for direct upload/install?)

Would be curious if this (is/could be) being considered by the team ? @Chris D @Paul B @Jeremy P

It would already help if I can get a simple

A. "yes, that will be possible with 2.3 natively" or
B. "no, that will not be possible with 2.3 natively" or
C. "it will only be easier for third party developers to offer a bridge between WP and XF"

to my question to be able to plan for the next 12 months.

@Chris D @Paul B @Jeremy P

 

[Kirby]

B. "no, that will not be possible with 2.3 natively"

This (if natively refers to both XenForo and WordPress) as WordPress (at least AFAIK) has no generic OAuth 2 client.

If "natively" refers only to XenForo:
It depends on the consumer (WordPress, etc.); if the consumer has native functionality to use a generic OAuth2 provider (eg. URLs and payload are fully configurable) if should work.

 

[SelamT]

Hello,

I created 2 new sites with version 2.3.
I defined OAuth2 client for one site.
I defined Connected Account for the other site to log in with OAuth2 client.
However, An error occurred while connecting with XenForo. Please try again later. error.

Everything in the pictures you attached is exactly compatible with what I did... but it won't log in.

Is there a detail I've overlooked that you can think of?

Do I need to make a setting other than what you describe in the pictures?

 

[snoopy5]

This (if natively refers to both XenForo and WordPress) as WordPress (at least AFAIK) has no generic OAuth 2 client.

If "natively" refers only to XenForo:
It depends on the consumer (WordPress, etc.); if the consumer has native functionality to use a generic OAuth2 provider (eg. URLs and payload are fully configurable) if should work.

Thanks for the quick response.

Another scenario:

I have several different XF installation. Each one on a different domain name. Each one on a different server, each one with its own database etc.

Is it possible with XF2.3 to make one forums the "master" for the registration and once the user is registered there, he is able to login and post comments in my other XF installations, although they are on different domain names and different servers?

 

[Kirby]

Is it possible with XF2.3 to make one forums the "master" for the registration and once the user is registered there, he is able to login [...] in my other XF installations, although they are on different domain names and different servers?

No, not directly.

You can connect your sattelite forums ("consumers) to your main forum ("provider") just as you can already connect your sattelite forums (again, the "consumers") to Facebook, X or GitHub (the "providers").

This connection allows users of the providers to easily sign up (and afterwards log in) to your forums without going through a full registration process (eg. enter username, email and password, maybe solve a CAPTCHA und most likely confirm email) - the registration process is basically shortened so they just must enter a username (and required profile fields) and accept your terms.

But they still need to register, they can't "magically" log in on sattelite forums without having an account there (just because they have an account at one connected account provider).

It is also not possible (without an Add-on) to turn off registration on your sattelite forums and only allow registration though connected account providers.

 

[roarijo89]

I heard the build is super buggy can you just make the 2Oauth a add on for now we really need this I want to purchase

 

[snoopy5]

No, not directly.

You can connect your sattelite forums ("consumers) to your main forum ("provider") just as you can already connect your sattelite forums (again, the "consumers") to Facebook, X or GitHub (the "providers").

This connection allows users of the providers to easily sign up (and afterwards log in) to your forums without going through a full registration process (eg. enter username, email and password, maybe solve a CAPTCHA und most likely confirm email) - the registration process is basically shortened so they just must enter a username (and required profile fields) and accept your terms.

But they still need to register, they can't "magically" log in on sattelite forums without having an account there (just because they have an account at one connected account provider).

It is also not possible (without an Add-on) to turn off registration on your sattelite forums and only allow registration though connected account providers.

What happens to the satellite XF forums ("consumers"), if the user deletes his account in the main XF forum ("provider")?

 

[Mendalla]

What happens to the satellite XF forums ("consumers"), if the user deletes his account in the main XF forum ("provider")?

They can still login using their original registered email or username and password, at least if this works the same as SSO with Google or similar. And use Forget Password if they don't know that password anymore.

 

[snoopy5]

They can still login using their original registered email or username and password, at least if this works the same as SSO with Google or similar. And use Forget Password if they don't know that password anymore.

Is their email then also in the database of the satellite XF forums ("consumers"), so that I can email them?

 

[Mendalla]

Is their email then also in the database of the satellite XF forums ("consumers"), so that I can email them?

Should be, I think. I have very few users with SSO but I am one of them and my email is definitely in the sites database since that's where it gets the email for sending notifications.

 

[jauburn]

I just want an out-of-the-box way to connect WordPress to XF and use XF as the registration vehicle. Methinks the techies should take care of the details and make this stuff easy. That's why we pay the money, no? I don't know what "Oauth" is, and I don't care.

 

[LuckyRiver]

Hi, so I played around with Oauth2, so far the authorization code is working fine, I was able to authenticate, get the code, use it to get an access token. But I have the following issue for my need on the Oauth2 request which has (registration info, token and a map of additional parameters). The map of additionnal parameters does not have information about the userId so that I can use it to retrieve his/her profile info using rest api call. It is like a map of key/value . Is this possible to have the userId in the additional parameters map so I can know which user is logged on? If not, how I can I get this information of the userId to retrieve his profile? I'm asking this because bdAPI which is an Oauth2 addon which I plan to replace with xf native Oauth2 has the userId info. Thanks!

 

[Luca_]

Could work then single login Wordpress --> Xenforo and/or xenforo-->Wordpress ?