Is the authentication process another domain or part of my business?

TL/DR: It is neither.

The domain or subdomain of your microservice is checkout management : is the order valid? are you allowed to checkout? etc...

Authenticating to your partner API is not the purpose of your microservice, it is an implementation details of how you store your state. That is because your service acts as an anticorruption layer above your partner's. You store your state in their service, and in order to do that, you need a token. This is the how, not the why. This can be demonstrated by the fact that, if your partner decides to change their API and switch to cookie based, or opaque tokens, or even a password sent to you by carrier pigeon, you'd have to change your code without changing the behavior of your service or application in the eyes of your users.

Authentication is not a part of your domain layer but of the infrastructure layer.

Or more acurately from a DDD perspective, it goes in a non-domain unit.

Does make sense move the logical of obtain a new token to another micro-service ?

TL/DR: probably not.

I suggest you read the excellent article Introducing Assemblage - a microservice architecture definition process by Chris Richardson about the generics of "should these things go in the same or separate service".

Reasons why you'd want to have it in a separate service would include :

• a very complicated process to acquire and store the token, that requires specific skills you don't have in the checkout service maintenance team and vice-versa
• that process changes very frequently and you'd benefit from faster deployment loop without risking to create regressions in the checkout service (or the opposite)
• acquiring the token requires access to secrets you're uneasy to share with people developping the checkout service
• performance wise, you'd like to have it hosted on a separate, more independantly scalable infrastructure
• security wise, you're uneasy to have your checkout service accessing the /token endpoint on your partner
• you'd benefit from have both services using different stacks because there are compatibility concerns between the stack you use in your checkout service and accessing your partner service and you can't easily switch them
• etc...

Other than that, you'd probably benefit from keeping the acquisition and storage of the token in your checkout service, at least at process-level. If you need to share that feature with other services and you are concerned about copy/pasting the code, you should rather look into making that code as a sharable library which can be embedded in each microservice (though that only works if these services have the same tech stack).

If you are concerned with the fact that scaling services will over-query the token endpoint on your partner, then you should better question how your services handle that token in the first place. Why query a new token every 6 minutes when a JWT has an explicit lifetime that probably exceeds that duration? Why query tokens continuously instead of requesting one on-demand?

If the problem is sharing tokens amongst services instances, then you'd probably look into a distributed cache. Setup a resilient KV store, such as redis, and store your token there. When a service needs access to the partner service, you check the redis store. If there is no token, our it has expired, you get a new one and feeds the cache. If there is a valid token, you retrieve it and use it to call the partner's api. This will save on your development manpower.