title: How should a Facebook user access token be consumed on the server-side?
body: <h2><strong>Preface</strong></h2>
  
  <p>I'm developing several web services and a handful of clients (web app, mobile, etc.) which will interface with said services over HTTP(s). My current work item is to design an authentication and authorization solution for the product. I have decided to leverage external identity providers, such as Facebook, Google, Microsoft, Twitter, and the like for authentication.</p>
  
  <p>I'm trying to solve the problem of, "when a request comes to my server, how do I know who the user is and how can I be sure?". More questions below as well...</p>
  
  <h2><strong>Requirements</strong></h2>
  
  <ol>
  <li>Rely on external identities to indicate who I'm dealing with ('userId' essentially is all I care about).</li>
  <li><p>The system should use token-based authentication (as opposed to cookies for example or basic auth).</p>
  
  <p>I believe this is the right choice for scaling across multiple clients and servers while providing loose coupling.</p></li>
  </ol>
  
  <h2><strong>Workflow</strong></h2>
  
  <p>Based on my reading and understanding of token-based authentication, the following is how I imagine the workflow to be. Let's focus for now on <strong>Facebook in a web browser</strong>. My assumption is that other external identity providers should have similar capabilities, though I have not confirmed just yet.</p>
  
  <p>Note, as of writing, I'm basing the following off of Facebook login version 2.2</p>
  
  <ol>
  <li><strong>Client:</strong> Initiates login to Facebook using the <a href="https://developers.facebook.com/docs/facebook-login/login-flow-for-web/v2.2" rel="noreferrer">JavaScript SDK</a></li>
  <li><strong>Facebook:</strong> User authenticates and approves app permissions (to access user's public profile for example)</li>
  <li><strong>Facebook:</strong> Sends response to client which contains user’s access token, ID, and signed request</li>
  <li><strong>Client:</strong> Stores user access token in browser session (<a href="https://developers.facebook.com/docs/facebook-login/login-flow-for-web#token" rel="noreferrer">handled by SDK conveniently</a>)</li>
  <li><strong>Client:</strong> Makes a request to my web service for a secure resource by sending along the user’s access token in the authorization header + the user’s ID (in custom header potentially)</li>
  <li><strong>Server:</strong> Reads user access token from request header and initiates verification by sending a request to the debug_token graph API provided by Facebook</li>
  <li><strong>Facebook:</strong> Responds back to the server with the user access token info (contains appId and userId)</li>
  <li><strong>Server:</strong> Completes verification of the token by comparing the appId to what is expected (known to itself) and the userId to what was sent on the client request</li>
  <li><strong>Server:</strong> Responds to the client with the requested resource (assuming the happy authorization path)</li>
  </ol>
  
  <p>I’m imagining steps 5-9 would be repeated for subsequent requests to the server (while the user’s access token is valid – not expired, revoked from FB side, app permissions changed, etc.)</p>
  
  <p>Here's a diagram to help go along with the steps. Please understand this system is <strong>not</strong> a single page application (SPA). The web services mentioned are API endpoints serving JSON data back to clients essentially; they are not serving HTML/JS/CSS (with the exception of the web client servers).</p>
  
  <p><img src="https://i.stack.imgur.com/KdE86.png" alt="Workflow diagram"></p>
  
  <h2><strong>Questions</strong></h2>
  
  <ol>
  <li><p>First and foremost, are there any glaring gaps / pit falls with the described approach based on my preface and requirements?</p></li>
  <li><p>Is performing an outbound request to Facebook for verifying the access token (steps 6-8 above) <strong>per client request</strong> required / recommended?</p>
  
  <p>I know at the very least, I must verify the access token coming from the client request. However, the recommended approach for subsequent verifications after the first is unknown to me. If there are typical patterns, I’m interested in hearing about them. I understand they may be application dependent based on my requirements; however, I just don’t know what to look for yet. I’ll put in the due diligence once I have a basic idea.</p>
  
  <p>For instance, possible thoughts:</p>
  
  <ul>
  <li><p>Hash the access token + userId pair after first verification is complete and store it in a distributed cache (accessible by all web servers) with expiry equal to access tokens. Upon subsequent requests from the clients, hash the access token + userId pair and check its existence in the cache. If present, then request is authorized. Otherwise, reach out to Facebook graph API to confirm the access token. I’m assuming this strategy might be feasible if I’m using HTTPS (which I will be). However, how does performance compare?</p></li>
  <li><p>The accepted answer in <a href="https://stackoverflow.com/questions/12065492/rest-api-for-website-which-uses-facebook-for-authentication">this StackOverflow question</a> 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?</p></li>
  </ul></li>
  <li><p>Is the signedRequest field present on the response in step #3 above (mentioned <a href="https://developers.facebook.com/docs/facebook-login/login-flow-for-web/v2.2#checklogin" rel="noreferrer">here</a>), equivalent to the signed request parameter <a href="https://developers.facebook.com/docs/facebook-login/using-login-with-games#checklogin" rel="noreferrer">here</a> in the ‘games canvas login’ flow?</p>
  
  <p>They seem to be hinted as equivalent since the former links to the latter in the documentation. However, I’m surprised the verification strategy mentioned on the games page isn’t mentioned in the ‘manually building a login flow’ <a href="https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow#confirm" rel="noreferrer">page</a> of the web documentation.</p></li>
  <li><p>If the answer to #3 is ‘Yes’, can the same identity confirmation strategy of decoding the signature and comparing to what is expected to be used on the server-side?</p>
  
  <p><img src="https://i.stack.imgur.com/2qLdU.png" alt="Decode &amp; compare from FB docs"> </p>
  
  <p>I’m wondering if this can be leveraged instead of making an outbound call to the debug_token graph API (step #6 above) to confirm the access token as recommended <a href="https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.2#checktoken" rel="noreferrer">here</a>:</p>
  
  <p><img src="https://i.stack.imgur.com/E7cGW.png" alt="debug_token graph API from FB docs"></p>
  
  <p>Of course, in order to make the comparison on the server-side, the signed request portion would need to be sent along with the request to the server (step #5 above). In addition to feasibility without sacrificing security, I’m wondering how the performance would compare to making the outbound call.</p></li>
  <li><p>While I’m at it, in what scenario / for what purpose, would you persist a user's access token to a database for example?
  I don’t see a scenario where I would need to do this, however, I may be overlooking something. I’m curious was some common scenarios might be to spark some thoughts.</p></li>
  </ol>
  
  <p>Thanks!</p>