slim-jwt-auth | PSR-7 and PSR-15 JWT Authentication Middleware | Authentication library

It is better to sign JWT using private/public key (RSA or ECDSA algorithm) instead of a secret (HMAC algorithm). In that case your auth service would sign JWT with private key and other APIs would validate JWT with public key, well... you still need to distribute a public key to your APIs then, but you have options.

Depends on your architecture, you might look at:

API Gateway pattern

For microservice architecture a good practice is to use API Gateway pattern. More about gateway pattern. API Gateway can validate JWT token and then proxy requests to your services. So auth service would sign JWT token with private key, then requests to APIs would go though API Gateway. API Gateway would validate token with public key, so you would not distribute public key to all APIs behind the proxy.

With this approach your would need an API Gateway, you can look at: express-gateway, kong + jwt plugin, tyk etc, also there is much more benefits from API Gateway rather then just JWT token validation, like traffic control, analytics, logging, requests and responses transformations and so on.

Secrets management

Instead of or additionally to API Gateway you can take a look at centralised secrets management systems, like Hashi Vault. Depends on the project/team size it could be an overkill for your project.

Doing:

The instruction you linked to states:

Callback is called only when authentication succeeds. It receives decoded token in arguments. If callback returns boolean false authentication is forced to be failed.

Do you meet this requirement when testing, i.e do you authenticate successfully? Also consider using var_dump($decode) instead of print_r($decode) when testing.