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
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, itsconnected_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.
