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

hys_8_cover.png
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:

hys_8_1.png


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:

hys_8_2.png


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

hys_8_3.png


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:

hys_8_4.png


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

hys_8_5.png


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

hys_8_6.png


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.
 
We can’t please everyone. But, as you can see, this is the most requested feature we’ve ever had so it’s an important one even if it doesn’t quite float your boat.
Sorry, I didn't mean to criticise this feature which is just fine. What I'm saying is I'm looking forward to those other features improvements which I'm sure are there. 🙂
 
Hope we'll be able to dress it up so that when someone registers on the forum they are registering for Example.com, and it's clear to see. That way we can go in another app and say Login with Example.com.

I also hope there will be a way to generate the "create an account with Example.com" in our own apps, piggybacking off the forum's account creation process and security.
 
I also hope there will be a way to generate the "create an account with Example.com" in our own apps, piggybacking off the forum's account creation process and security.
Note sure what you are talking about ...

If Example.com runs XenForo 2.1+ you can create an account on that XenForo via "your own app" using the API and an API key.
With XenForo 2.3+ you can do that with with OAuth as well (instead of XenForo native API key) - but you would of course still use the same XenForo API.
 
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:

hys_8_4.png
The authorization screen shows only API scope user:read.
I assume it's possible to configure the scopes a client may request when creating / editing the client?
Is it possible to set further restrictions (like IP address / CIDR, valid & expiry date)?
 
Great news. Would be nice to see a setup guide for OAuth using one of the platform agnostic self-hosted auth platforms... Like Ory's ;)
 
It's great to see both webhooks and Oauth implemented, because these bring us 2 steps closer to the implementation of my suggestions. Thank you!
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.
Not exactly: We are not there yet. From the suggestion thread:
I posted this suggestion because the original top voted suggestion for an API, did not implement SSO nor members synch.
If this suggestion for SSO/oauth gets implemented, then I do hope that a sync of member base is also included. And that it will be implemented in a way that there will be no need for a third suggestion for member sync between installs. What I would like to see is to be able to connect multiple sites so that the same member base can have a profile on all sites, and a user change on one site will affect the other sites. For example: if a user purchases an account upgrade on one site, then the account on the other site(s) would also receive the upgrade.
It seems I will need to repost this most popular suggestion for the third time? The first and the second one both got hundreds of votes, were the top voted suggestions and took years.
Please consider to add member sync in xf2.3. The whole point of the first two suggestions is to have the same members with the same usergroups on multiple sites. i.e. if an account upgrade or a promotion happens on one site, then it changes on the other sites as well.
 
Back
Top Bottom