This sounds different from what I've heard about previously. My understanding of a typical microservice architecture is that you'd have a variety of fine-grained microservices, composited together into one or more coarse-grained applications.
In that view, you would probably have a single E-Commerce Web App, which utilizes a variety of microservices in the backend (the cart service, suggestion service, search service, etc.).
If that's the case, then there's only one "App" that the user interacts with: the Web App. The user would sign into the Web App, and then the user's ID would be delivered to the various back-end microservices.
If the Web App talks to the backend services using a private interface, then you can just pass the user ID directly - it's not really any different from passing, e.g., a user ID into a database query. If you've got a public interface that you're using, then you might need to pass something like a session key around - although, that would depend on exactly what sort of public interface you have.
Note: all of this assumes that you're talking about a server-side microservice architecture, since you cite list "rails" as a related technology, but not anything specifically client-side. Using web APIs over Ajax is something that I'd consider to be a separate topic.