Let’s look at the various parts of your question.

I understand services should have no state and no business logic.

Your statement (and assumption) is only partly correct.

• Services should not have state.

This is mostly true, rounded up to almost always true. The problem is that coding state into a service gets to be a real pain. Keeping track of the state; client requests; timeouts; disconnects; slow responses; load balancing; distributed service provisioning; session hijacking; etc… all adds up to a lot of overhead. So it’s just easier to not have state in the service. The problems listed mostly go away, and the features are easier to implement.

• Services should not have business logic.

Not true. In fact, a service is essentially a manifestation of business logic. A service must provide a function. That function represents something of value to the business, and is generally a piece of the organization’s business logic.

All the methods in a service should be static?

I think this depends upon what you mean by static. If by static you mean only a single instance of the service, then the answer is “maybe.” And I think this aspect would be driven more by your language of choice for the service than anything else.

But if you mean “unchanging” then the answer is yes. A service should provide a deterministic response to a properly formatted response. How it generates that response may change, but the form and nature of the response should be static. A service is an API, and once released to the wild then it should not change. If a change is required then consider applying versions to your services.

How can you implement a service like AuthentificationService considering these rules?

See above for the misunderstandings in your base assumptions.

Many frameworks provide this service out of the box so long as you plug the framework into your authentication provider. The general approach is that credentials are based to the Authenticate service which returns an ephemeral token upon successful authentication. The other client based calls then make that token part of their call to the other services. Those services or an intermediate layer verify that the token is still valid and then allow the service call to proceed.

You could make the semantic argument that the token represents a “state” for the client session. But the token or “state” tracking is handled by the client and there are very simplistic rules on the service side in order to validate and handle that “state.” Many / all of the woes associated with stateful services are still avoided.