Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using auth.authorize without res and scope #51

Open
JPluim opened this issue Nov 24, 2015 · 3 comments
Open

Using auth.authorize without res and scope #51

JPluim opened this issue Nov 24, 2015 · 3 comments
Labels

Comments

@JPluim
Copy link

JPluim commented Nov 24, 2015

Right now it is not possible to use auth.authorize without res and without wanting to pass scope variables (because you want to use the standard ones set in the API of the provider).

Side note: I'm using node-linkedin now without the authorize step (because in an AWS lambda environment I'm handling the code frontend with Satellizer and handling the access_token retrieval backend with node-linkedin. If I got the code correctly, I do have to first call auth.authorize now to set the state in de module, before being able to call auth.getAccessToken. Isn't this maybe an improvement?)

@ArkeologeN
Copy link
Owner

That is not correct. If you already have the access token available, you can just initiate your instance object with the token:

var linkedin = Linkedin.init('my_access_token');

Regarding the authorize method, you can still use it without res argument but you have to mention the scopes i.e

var auth_url = Linkedin.auth.authorize(scope);

Even skipping the scope would not let you match your scopes between the selected ones on the Linkedin Portaland the application ones.

Let me know if I got you correct.

@JPluim
Copy link
Author

JPluim commented Nov 24, 2015

I'm getting the first part now indeed. But is it necessary to explicitly set the scopes? The LinkedIn API states that in the request scope variables don't have to be passed. When they aren't passed the standard ones in the Linkedin Portal are used in that case. Now the scopes are matched against being an Array, while you in fact don't have to pass scopes right?

About the side note. I don't have the access token available yet, that's the whole point. But in Linkedin.auth.getAccessToken(code, state, callback) the state is matched against the stated which is saved in the object (which is saved when doing Linkedin.auth.authorize(). If you don't call authorize() first, a state-token isn't saved and therefor getAccessToken returns a

Possible CSRF attack, state parameters do not match.

This is correct right? If you'd make the check against the saved state in the object check if the state in the object is set, then you can also provice the getAccessToken method when not first calling authorize().

@ArkeologeN
Copy link
Owner

scopes: Fair enough, I wasn't acknowledged that its OK to not pass the scopes in request and it will match with the preset ones from LinkedIn Portal. I'd welcome a pull request from you for the change.

state: I think I got your point. You're referring in a case if you didn't use the wrapper to initiate the authentication and then you have to phase the error message as the stateOut doesn't match with the applied states:

https://github.com/ArkeologeN/node-linkedin/blob/master/lib/auth.js#L66

Which is practically OK and important from the security standpoint. Perhaps, you can also input your state while calling authorize() or while initializing the LinkedIn object.

https://github.com/ArkeologeN/node-linkedin/blob/master/lib/main.js#L10

var Linkedin = require('node-linkedin')('app-id', 'secret', 'callback', 'state');

In either case -- you need to be aware of the state you're exchanging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants