Vulnerability with Facebook token hijacking

According to Facebook manual for developers (https://developers.facebook.com/docs/facebook-login/security) you don't have to use access_token from some sort of Facebook SDK clients without ensuring that it was generated specifically for your Facebook application.

I'm wondering what kind of vulnerabilities has place here. Why I should care about which app received token if I can use it to make API calls and get user data through it?

Token Hijacking

To understand how this happens, imagine a native iOS app that wants to make API calls, but instead of doing it directly, communicates with a server owned by the same app and passes that server a token generated using the iOS SDK. The server would then use the token to make API calls.

The endpoint that the server uses to receive the token could be compromised and others could pass access tokens for completely different apps to it. This would be obviously insecure, but there is a way to protect against this - access tokens should never be assumed to be from the app that is using them, instead they should be checked using debugging endpoints.

These types of vulnerability are application specific - one scenario I can think of is this:

Imagine you are using Facebook authentication as a SSO mechanism and have created an app with a webservice that returns some private information to authenticated users. This webservice is called /secretdocuments/download which takes an access token as a parameter.

If the webservice only checks that the access token it receives is for a user it has in the database (via a call to /me and then a DB lookup), then a malicious person could:

Create some other "bait" app.
Send a link to that app to one of your users and encourage them to install it.
That user authenticates with the bait app and an access token is generated. The bait app sends this access token to the malicious user.
The malicious user takes that access token and calls your /secretdocuments/download webservice with it.
Your webservice only checks that the access token is for a user which is in the database and returns the private information to the malicious user.

In this scenario, your webservice must check that the access token provided was generated by your application.