[nodebb-plugin-sso-oauth] How to associate with current logged in user. [solved]

[KingCat]

So I finally relented and decided to go with OAuth2 after much debate and research. It seemed like the safest way to go with the least amount of holes poked into my authentication system.

I was able to modify this plugin to suit my needs and I got it working with an API endpoint that auto-generates random user information. The problem I have is how to link the API endpoint that's called from within node (not from the user's browser) to associate with their current session. In other words, how do I associate this server-side node call with the originating request made by the user in their browser.

To help explain this is what i've got:

Nodebb is running from https://forum.nzb.cat

This is the library.js config from my modified nodebb-plugin-sso-oauth:

constants = Object.freeze({

            type: "oauth2", // Either 'oauth' or 'oauth2'
            name: "nodebb", 
            oauth: {
                    requestTokenURL: '',
                    accessTokenURL: '',
                    userAuthorizationURL: '',
                    consumerKey: '',
                    consumerSecret: ''
            },
            oauth2: {
                    authorizationURL: 'https://auth.nzb.cat/oauth/authorize',
                    tokenURL: 'https://auth.nzb.cat/oauth',
                    clientID: 'CLIENTIDSSS',
                    clientSecret: 'SECRETZZ',
                    state: 'xyz'  //had to append this var to the object or the oauth server explodes.
            },
            userRoute: 'https://nzb.cat/resource'  
            }),

Now the nzb.cat/resource endpoint is programmed to output a json representation of the currently logged in user. It validates a successful oauth handshake by parsing the token provided. The issue is the call comes from node itself and not the browser, so there's no currently logged in user from it's perspective, it has nothing to output.

How do I securely "mark" which user is logged in so the process can pull the proper user later on.

And just one last time to make it clear, the entire oauth2 process works great, i get a token and access code without issue, it's just how to denote which user to log in.

I feel kind of stupid I got this far and seem to be missing a major piece. I looked at the other oauth plugins for some help but I couldn't make heads or tails of them for some reason. I'm still not that strong with event based systems.

Also, BTW, you won't be able to hit any of those oauth2 URL's, I have them locked down to specific ip addresses for obvious reasons, I pulled out the client_id and secret because reasons.

[KingCat]

Any chance the original plugin dev @julianlam can pop in and let me know what the ideal implementation would look like? I've found forks of his plugin on github and most of them seem to have identical implementations. I'm not sure how they got around the lack of session information in the final user route

[julian]

@KingCat When the token is retrieved after the "OAuth Dance" is complete, your plugin should use that token to call the user route. This route is different for all implementations, hence why it cannot be assumed or hardcoded.

This route returns user data, including (hopefully) identifying information that your plugin can use to determine which user to log in. Email is usually the value I use.

Once you find out which uid it is, req.login({ uid: thatUid});

[KingCat]

@julianlam Thanks, thats exactly how I understand it and I was able to implement it that way. My question is, how do I associate the currently logged in user with this "oauth dance"? The final endpoint that's hit with the token doesn't have any user identifiable information in it, and I can't pull the user data based on the session since the call comes directly from node and not the users browser.

Am I supposed to associate that token with the user somehow?

[julian]

Am I supposed to associate that token with the user somehow?

Yes, that ^. During the OAuth token granting stage, you associate the newly created token with the user.

Then when that token is used to call the user route, you can authorise the bearer token and return the appropriate user data.

You don't have to use passport-http-bearer, you could technically just parse the incoming header for the bearer token and return the user data. The module just simplifies things (even though it sure doesn't seem like it at first pass!)

[KingCat]

@julian Thank you so much for your help. I finally got it working. I had to ditch the intermediary auth server and integrate oauth2-server-php directly into my application so I could associate the currently logged in user with the authentication dance.

Thanks again for your help, I was really confused.

[julian]

No problem. OAuth is tricky, especially if you're implementing it for the first time. Even I only have a basic grasp of the concepts, but I'm glad we could figure it out

[KingCat]

For anyone else that may find this post and is struggling, this step by step walkthrough really helped me out (at least regarding the php oauth2 server) http://bshaffer.github.io/oauth2-server-php-docs/cookbook/