Handling tokens stored behind different microservices

Question

I have a very interesting question that has proportionally blown up amongst my friends and I. This deals with handling user issued tokens from a series of authentication microservices.

Remarks:

• Each Auth Service is backed by its own data store
• Each Auth Service can issue a token that only its data store knows about

Here's a minimal example of the problem:

Using the Microservices Architecture

We have a Master API Service that delegates all requests to the requested service

We have two Authentication Services that sit behind the Master API Service
    Auth Service 'A'
    Auth Service 'B'

If 'A' issued an authentication token the User 
    The token will be stored in a JWT
    The JWT will be signed by the unique KEY to service 'A' only

The User makes an authentication request using their issued token
    How does the Master API Service know which Auth Service it should validate the 
    token against?

Approaches we have thought of:

• Approach A: Store some metadata in the JWT claim that contains useful information pertaining to which Auth Service issued it.
  • Issue: Each Auth Service signs the JWT differently. This leads us back to the original problem.
• Approach B: Issue authentication requests to each authentication microservice and if one validates the claims then it must contain the token
  • Issue: This defeats the purpose of microservices

Can anyone shed some light on this problem? Perhaps we are just overthinking the solution.

Answer 1

The token doesn't have to be the only data sent back to the user when the token is issued. It's very common to include a header or cookie that describes the auth mechanism, or the source of the auth token, so I would add a cookie X-Auth-Issuer that would be sent to the user when the JWT is issued, and the user would continue to send that cookie to the master with each request. The master would look up the value of the cookie in a data source or configuration to decide which auth service the JWT was issued by.

Service registry is not uncommon with central authentication services (e.g. CAS). Services are known ahead of time so that nothing can just start posing as an authentication service.