You could create UUID that is a sole identifier of the user. The authentication service will be responsible for creating this. Once a user has passed through the authentication service, it will has the unique UUID, that can be passed to other services, in your case, the article service.
The frontend could keep that UUID in a session so it remains, or you could request an authentication every page reload, or you can use JWT.
In an ideal world, each service doesn't really know about the others. However, data is doesn't work like that. Data needs to know about other data sometimes. In such a case, you need common ground, passing a user id or token will allow you to identify the individual making articles.
It's also completely fine for your articles service to make requests against the Authenticate service, for example, if you need to get the user that created the article based on the Id. Make a request to the Authenticate service for it, get the details.
You could go even further, and break up Authenticate service into Auth and User. Auth is literally just for authenticating details and user is for polling/creating users.
Another advantage of doing that way is testing. Your tests are simpler and more focused when you only need to worry about creating/deleting a users/article/etc, rather than also authenticating it.
- Another point to make - You could later consider Docker Files and Kubernetes to start to string those together. This is something I believe Netflix do. There is good video on YouTube where they talk about it, but I can't seem to find it. Sorry.