How should you deal with auth and sharing Users info across microservices?

An authentication layer as its own application fits pretty well in SOA design. There is an HTTP endpoint with no direct access to the micro-service database which what SOA best practice is:

For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services.

-- Werner Vogels, Amazon CTO

Reference to http://martinfowler.com/microservices/

What is an authentication layer or service and how does one server confirms the authentication has been established yet? One kind of client based persistence is HTTP cookie which hooked strictly to a domain name, therefore it is not easy to reuse same cookie among multiple domains without an explicit authentication step.

If you are able to pass a certain key or header http_request can provide unobtrusive authentication, this module became a built in Nginx core since version 1.5.4: http://nginx.org/en/docs/http/ngx_http_auth_request_module.html

location /upload {    auth_request /auth;    ...}location = /auth {    internal;    proxy_pass http://auth_service.localhost;    proxy_pass_request_body off;    proxy_set_header Content-Length "";    proxy_set_header X-Original-URI $request_uri;}

The endpoint accessible through http://auth_service.localhost (choose your own URL) is isolated and has its own database and does only one thing - to authenticate user or not. A mechanism can rely on a certain key or header or even IP address. To suppress to much subsequent request you can cache the response.

SOA is hard but I recommend to read this thoroughly: https://www.nginx.com/blog/introduction-to-microservices/