Use LinkedIn JSAPI credentials cookie to authenticate a user

3
votes

We would like to implement "Sign-in with LinkedIn" in our app. Since the app has JS fronted and RESt-based backend, we decided to exchange JSAPI tokens for REST API OAuth tokens as described here.

If a user successfully signs in, the frontend sends credentials cookie with client-side bearer token and member ID to the backend. On the backend we check if a user with such a member ID already exists and if not, we exchange JSAPI token for REST API OAuth token, retrieve user details from LinkedIn a store it in our database.

Now the question is if we can use that cookie to authenticate each user's request to our REST backend. After a user successfully signed in via JSAPI, the cookie should be automatically passed to our backend on all subsequent requests so we can check member ID. Are there any drawbacks that we missed? Or is this idea as a whole wrong?

Should we rather authenticate a user only once by means of the cookie and then issue our own authentication token and send it back to the client?

2
restauthenticationoauthlinkedinlinkedin-jsapi
why you want exchange token.if you want to save user profile.you can use javascript callback function and send ajax request with user details and do what you want. - naveen goyal
So what you suggest is to do OAuth dance on the client side, get user profile and then send the details to the server? - Nathan
I would not recommend doing the oAuth dance on the client side. It's not particularly secure and people could intercept and alter the data before it's transmitted to your server. Use the secure cookie, convert the token server side and go from there. - Matt

2 Answers

1
votes

The way cookies work in general is they are passed on every request to the domain they belong to. LinkedIn is setting a credentials cookie to your domain.

As long as you are validating those credentials on every request it's perfectly acceptable to use their tokens as authentication.

Personally I don't find that to be a great idea and would prefer to validate their credentials once and create my own auth token to use from there on out. You can always set that token to expire at some-point and re-validate the LinkedIn credentials (which will still be getting sent on every request anyway). This limits the amount of times you're checking with LinkedIn and should increase the responsiveness of your app.

1
votes

Either way could work.

If you are using the LinkedIn cookie to validate a user by member id, you should validate the cookie's signature on each request per section 2 of the doc you linked and question 2 of the FAQ.

Using your own token could make it easier to implement an account which belongs to your app and is not necessarily connected to LinkedIn, assuming there's the potential to either connect solely with some other service(s) or no 3rd part(y/ies). Still should validate any time you trust the member id in the cookie though.

The doc provides a validation example in PHP, and if you're interested in improving a ruby version, I have a shameless plug.

The flow that you've outlined in your latest comment of going straight for the OAuth tokens is the best way to go if you were only signing in to convert the JSAPI tokens to OAuth tokens and then not using the JSAPI further. If you were planning to actually use both the JSAPI tokens within your front-end app and the OAuth tokens on your back-end, then it's better to take the conversion route.