title: Microservice Authentication strategy
body: <p>I'm having a hard time choosing a decent/secure authentication strategy for a microservice architecture. The only SO post I found on the topic is this one: <a href="https://stackoverflow.com/questions/25595492/single-sign-on-in-micro-service-architecture">Single Sign-On in Microservice Architecture</a></p>
  <p>My idea here is to have in each service (eg. authentication, messaging, notification, profile etc.) a unique reference to each user (quite logically then his <code>user_id</code>) and the possibility to get the current user's <code>id</code> if logged in.</p>
  <p>From my researches, I see there are two possible strategies:</p>
  <h3>1. Shared architecture</h3>
  <p><img src="https://i.stack.imgur.com/po7Qr.png" alt="Shared architecture" /></p>
  <p>In this strategy, the authentication app is one service among other. But each service must be able to make the conversion <code>session_id</code> =&gt; <code>user_id</code> so it must be dead simple. That's why I thought of Redis, that would store the key:value <code>session_id:user_id</code>.</p>
  <h3>2. Firewall architecture</h3>
  <p><img src="https://i.stack.imgur.com/NHGjh.png" alt="Firewall architecture" /></p>
  <p>In this strategy, session storage doesn't really matter, as it is only handled by the authenticating app. Then the <code>user_id</code> can be forwarded to other services. I thought of Rails + Devise (+ Redis or mem-cached, or cookie storage, etc.) but there are tons of possibilities. The only thing that matter is that Service X will never need to authenticate the user.</p>
  <hr />
  <p>How do those two solutions compare in terms of:</p>
  <ul>
  <li>security</li>
  <li>robustness</li>
  <li>scalability</li>
  <li>ease of use</li>
  </ul>
  <p>Or maybe you would suggest another solution I haven't mentioned in here?</p>
  <p>I like the solution #1 better but haven't found much default implementation that would secure me in the fact that I'm going in the right direction.</p>