To send calls to either the centralauth-service or DFSP's ownauth-service, we need some way to specify the endpoints for the auth-service ahead of time.
Our current thinking was that we could store whether or not the DFSP is using the central or their own auth-service in the ALS, but that doesn't really solve the problem of making sure the requests go to the right place.
What we need is a router, like what we have with all other mojaloop services.
Solution
I think the thirdparty-api-adapter should be the one responsible for routing auth-service requests (/consents, /consentRequests) to the correct auth service based on the FSPIOP-Destination header. That way, we can store the callback urls as we are doing with all the other services (in central-ledger), and simply lookup the callback urls based on the dfspId.
This could also remove the need to store any references to the auth service in the ALS, since the url configuration for a given participant will be enough to get the
The Challenge
To send calls to either the central
auth-service
or DFSP's ownauth-service
, we need some way to specify the endpoints for the auth-service ahead of time.Our current thinking was that we could store whether or not the DFSP is using the central or their own
auth-service
in the ALS, but that doesn't really solve the problem of making sure the requests go to the right place.What we need is a router, like what we have with all other mojaloop services.
Solution
I think the
thirdparty-api-adapter
should be the one responsible for routingauth-service
requests (/consents
,/consentRequests
) to the correct auth service based on theFSPIOP-Destination
header. That way, we can store the callback urls as we are doing with all the other services (in central-ledger), and simply lookup the callback urls based on thedfspId
.This could also remove the need to store any references to the auth service in the ALS, since the url configuration for a given participant will be enough to get the