NodeBB Oauth SSO Plugin and Wordpress
-
Thanks for your inputs. I am still trying to figure the SSO thing out, perhaps I have bitten off more than I can chew. The /auth/generic/ callback/ results in a 404, indicating misconfiguration on my end and the request token url I have entered in NodeBB SSO plugin config is most likely faulty. I think this needs more research on my end.
-
Ok, I haven't made much progress, this is a bit more complex than expected. I had naively presumed the 2 Oauth plugins on both sides would be friends and play nice.
But not to be. You need to debug the Wordpress Oauth2 Provider plugin to understand what data it is passing and how, and then the NodeBB SSO plugin needs to be customised to parse this data properly.
For anyone who is familiar with the NodeBB SSO plugin this is how the Wordpress Oauth plugin works.
Once you install the plugin the Oauth2 gateway becomes available at - example.com/oauth
To add a consumer you simply enter a name and redirect URL and the plugin gives you the client id and client secret codes.
You make a authorization request ( request URI needs to have state=anything_you_want, client_id=client id, response-type=code&redirect_uri=http://nodebb.org #using this just to debug
This is what you get back from the gateway
http://mynodebb.org/?state=2020&code=d5543c2b60338de3bd0e3663ccb42e1e0dd6b028
code= is the authorization code. You need to use this code to make a token request like this
This is what you get back from the gateway - the access and refresh token - yeh!
{"access_token":"e9ca0772593294bcc4d3d506e6dfdc5a87f73525","expires_in":3600,"token_type":"bearer","scope":"","refresh_token":"e70c3cbafa5941ae05ec5a9b40014b5948c72561"}
You now need to use the access_token to get the user data like this
And this is what you get back - viola!
{"ID":"3","user_login":"vanilla","user_nicename":"vanilla","user_email":"[email protected]","user_url":"","user_registered":"2014-07-05 16:18:31","user_status":"0","display_name":"vanilla"}
Now to make this work for real the NodeBB Oauth SSO plugin needs to be modified to follow the above flow to get the user data and register the user for SSO. I looked at the twitter, facebook, and Google plugins for reference but its far from simple without real coding skills. Help!
-
I was looking at the facebook, github, twitter and Google SSO files and comparing them to the standard oauth plugin. Each of them has a slightly different way to get user profile data.
The other thing I noticed is there may be some lack of standardization with Oauth2. For instance the Wordpress oauth2 plugin requires a 3 step process; authorize url, request token url, and request access url.
In the Nodebb plugin the Oauth2 pluggin only has entries for a authorize and request access url, so its missing the request token url which is probably a reason its failing. Or the Oauth 2 Wordpress plugin is not coded properly.
The Nodebb Oauth1 does have an entry for request token, I tried that and it doesn't work and results in an 404 error. At least with the Oauth2 you do get redirected to the Wordpress login, but fails when redirected back to Nodebb.
One more thing I discovered on this SSO side trip, is Discourse has SSO working out of the box, and its super simple to set up with any php based website, there is a specific Wordpress plugin - a one page php file, and it works. Given how tough a lot of things are with Discourse for those not familiar with Ruby this was a genuine pleasant surprise for me.
-
Hi @raul, sorry for the delay in getting back to you:
Facebook, Google, and Twitter SSO plugins are using specially built Passport plugins to streamline the OAuth process. In addition to handling the OAuth process through passport, the individual plugins also consume the remote API for you, and normalise the data into a consistent format (so the data returned from Facebook is of the same format as Twitter, even though their APIs are very different).
There is one for WordPress as well, but it is only for WordPress.com login, not individual WordPress sites. This is where sso-oauth plugin comes in.
I can get you far enough so that given a key and secret and the OAuth URLs, I can negotiate the start the exchange, get the code, and retrieve a token, but everything after that is up to you, since every API is different.
As far as I know, the OAuth2 version of sso-oauth will do the entire process: Initialisation, reception of the code, exchanging the code for a token, and saving that token to the database, so the user does not have to re-authenticate every time he/she needs to do something.
-
@Julian, thanks for replying, I know you must be super busy with 0.5 release.
Yes, I think a Wordpress plugin will be great to have for a lot of Wordpress users looking beyond the usual forums to newer and more modern options like Nodebb.
On the Wordpress side the Wordpress Oauth2 plugin does give the user data, but after specific requests to the authorize, request token and request data URLs and the Nodebb Oauth2S strategy from what I could discern does not account for a request token, only an authorize and access/ refresh token so there is obviously some mismatch happening here.
Maybe the Wordpress plugin is not sticking to the Oauth2 standards strictly.
The Discourse inbuilt SSO approach is also interesting. For instance the code for integrating Discourse with any php based website, or Wordpress for instance is a single php page. Maybe it will be worthwhile having a look when you have some time. See here for the details . Discourse SSO plugin
-
For instance the code for integrating Discourse with any php based website, or Wordpress for instance is a single php page.
I like the concept. Sounds like it wouldn't be too much work to build something like this
Maybe I'll give it a shot
-
@psychobunny cool!, that will be nice to have! Here is the Discourse page that talks about their single sign on and how it works with some examples and the SSO discourse code.
-
I read through the article. Instead of playing nice with other websites, Discourse is instead reversing the SSO process, with a new format that must be built against their existing SSO schema.
... meaning if you wanted to enable logins via your WordPress install, and there isn't one already built, you'd have to write a WordPress plugin that consumes the Discourse SSO API.
I'm not saying this is a bad idea, I'm trying to think critically of both options (Ours vs. Discourse)...
Discourse SSO
Pros
- Once a WP plugin is built, it does not need to be built again
Cons
- Only one external login method is supported
- If you wanted to allow Google Accounts and accounts from your WordPress install, this is not possible
- SSO plugins for major providers must be done from Discourse, whereas minor providers (e.g. a self-hosted WP install) must be done to Discourse. This flip-flopping is confusing.
NodeBB SSO
Pros
- Public APIs for all major sites are already built (via PassportJS), trivial to create a plugin if already supported by PassportJS (fork existing fb plugin, change parent library).
- Once a NodeBB SSO plugin is built, it does not need to be built again
- All SSO integration is done from NodeBB
Cons
- A NodeBB plugin must be built for each OAuth provider
- ... or customised to consume an OAuth endpoint provided by something like OAuth2orize
- Establishing integration for a minor provider means work must be done at both ends (WP OAuth plugin and NodeBB plugin)
Final Thoughts
- As mentioned prior, the idea that some SSO integrations are one way, while others are in reverse is confusing, and places minor providers as second-class citizens (major providers allow login via other providers, while minor providers take over the login process completely)
- Both methods pose a significantly high barrier to entry (programming knowledge required until plugins have been created)
- Handling your own encryption and security for login is scary, and I don't pretend to know everything about it. This is why NodeBB uses bcrypt for password hashing, and depend on other providers to properly maintain login integrity.
-
@Julian I was vaguely aware of passport, but I just had a closer look and it's seems like an great plugin to have with over 50 mainstream sites strategies already available.
I hadn't really thought about the Discourse con of only one external login but when you thinkabout it but it is a big con. Ideally you want to have multiple login options for end users so that's some thing to think about.
The Nodebb cons are also to be considered, even with passport there is still a bit to be done for each provider.
-
Ok guys, here is my first stab at trying to get the Wordpress plugin working and I am failing miserably so far. I keep getting a 404 at Nodebb whatever I do. Frustrating.
@Julian thanks for the passport link, I was vaguely aware of it and since I am currently trying to understand SSO and have been reading the OAuth 2.0 draft it was helpful to go through all the strategies.
WIth my slighter better understanding the Google SSO plugin seems to be the closest fit to the Wordpress Oauth2 plug in.
Here is a screenshot of the token endpoint
And of the access user profile endpoint
And here is my first attempt at a custom strategy. The data is provided in json by the wordpress plugin. Only including the changed bits from the Google Oauth2 strategy. Please note the Wordpress Oauth 2 plugin does not work without the 'state=' parameter.
function Strategy(options, verify) {
options = options || {};
options.authorizationURL = options.authorizationURL || 'http://example.com/oauth/authorize?state=2020';
options.tokenURL = options.tokenURL || 'http://example.com/oauth/request_token';OAuth2Strategy.call(this, options, verify);
this.name = 'wordpress';
}Strategy.prototype.userProfile = function(accessToken, done) {
this._oauth2.get('http://example.com/oauth/request_access', accessToken, function (err, body, res) {
if (err) { return done(new InternalOAuthError('failed to fetch user profile', err)); }try { var json = JSON.parse(body); var profile = { provider: 'wordpress' }; profile.id = json.ID; profile.displayName = json.user_nicename; profile.name = json.user_login; profile.emails = [{ value: json.user_email }]; profile._raw = body; profile._json = json; done(null, profile); } catch(e) { done(e);
-
Any update on a Wordpress SSO?
-
@Tanner said:
Any update on a Wordpress SSO?
Should be pretty simple to be honest. There's a passport for it. For you, I'll see what I can do.
EDIT: The passport is for Wordpress.com
Damnit.
I'm going to have to install Wordpress and look through a few plugins.
-
Hey Everyone,
I know this thread is a bit old but I thought I would chime in here being the developer of the WP OAuth Server plugin you mention here.
@Tanner I recently published the OAuth client plugin for WordPress. If you are still interested, you can visit https://wp-oauth.com. The plugin is a premium plugin but is very reasonable.
To everyone else, I am not familiar with the platform you are using but I do have a very good understanding of security, authentication via WordPress and core of WP OAuth Server. I am open to helping where ever I can. If anyone needs a hand, shoot me an email, reply back here or submit a support request either on at https://wp-oauth.com or the WP forums.
Looking forward to helping where I can.
-
@Justin-P-Greer Very cool to have you here. Welcome!
Poor @raul has been waiting months for this, and I promised to help him out but I ended up getting very sidetracked by other issues with NodeBB.
As long as your WP plugin can establish a standard OAuth2 endpoint, we can probably build something against it.
-
The plugin uses the "oauth/authorize" and "oauth/token" for authorization. This is to spec for OAuth2. Now as far as the resource API, there is no spec given as long as the acess token is given. Current the endpoint for the user resource is "/oauth/me?access_token=xxx". The "me" endpoint is there by default and returns basic information about the user from WP user meta fields. It can be modified very easier using WP filters.
You can visit the documentation or just shoot me an email if you need anything.
-
I'm interested in this too. Was exactly thinking about using your wp plugin to achive the mentioned functionality. What a coincidence.