How should a Facebook user access token be consumed on the server-side?

Question

Preface

I\'m developing several web services and a handful of clients (web app, mobile, etc.) which will interface with said services over HTTP(s)

Answer 1

1. I dont' see any glaring gaps / pit falls, but I'm not a security expert.
2. Once your server has verified the given token (step 8), as you said:

The accepted answer in this StackOverflow question recommends creating a custom access token after the first verification of the Facebook user token is complete. The custom token would then be sent to the client for subsequent requests. I’m wondering if this is more complex than the above solution, however. This would require implementing my own Identity Provider (something I want to avoid because I want to use external identity providers in the first place…). Is there any merit to this suggestion?

IMHO is the way to go. I would use https://jwt.io/ which allows you to encode values (the userId for example) using a secret key. Then your client attach this token to every request. So you can verify the request without need to a third party (you don't need database queries neither). The nice thing here is there is no need to store the token on your DB.

You can define an expiration date on the token, to force the client authenticate with the third party again when you want.

5. Let's say you want your server be able to do some action without the client interaction. For example: Open graph stories. In this scenario because you need to publish something in the name of the user you would need the access token stored on your DB.

(I can not help with the 3 and 4 questions, sorry).