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.
To clarify my reference to November in the original post was intended to be 2024.
Stop the count! You can't make us wait another year!!


On a more serious note lol I am looking forward to 2.3 now more than ever given it's going to be packed with a bunch of useful features and enhancements I've been looking for, especially coming from Flarum, and previously using XF and even VBulletin in another life.

Bring it on!!!
Are we going to be able to download Beta releases? I'm thinking about building a new website with XF 2.3.

Yes, but they're unsupported. So if there's a bug with upgrading (not likely in my experience) to the next version you'll have to rely on your own expertise and/or community support to get it fixed, or you'll have to scrap it and start over.
Top Bottom