Architecture - Whether/Where to store 3rd party IDs

Question

I've got an application where users can log in with varying levels of permissions. From their client they send a username & password to the front end, which passes it to the back end, and from there we've got a few different calls.

Assuming things go well at each step:

1. Check a username & password with our Identity Authentication Service.
2. Look in our local database for the user's preferences related to the app.
3. Send username to Authorization Service A, get back ID_A.
4. Send ID_A to Authorization Service B, get back ID_B.
5. Send ID_B to Authorization Service B, get back user authorizations related to the app.

Finally we'll package up the preferences and authorizations in a token, sign it, and pass it along back to the client.

A few notes for context:

• ID_A doesn't change.
• ID_B may or may not exist if the user has has very few authorizations; if we don't get an ID_B back, that's fine, they just have almost no access.
• If ID_B does exist, it's going to change very infrequently, on the timescale of months or years if at all.
• The user authorizations from service B also changes infrequently, but it's important to the business logic to verify these authorizations at every login.
• Authorization Services A & B are both 3rd party vendors. Unlikely to change anytime soon, but never say never.

Option 1

The three calls I'm making to the authorization services seems like a lot, so I'm thinking I could short-circuit things by saving ID_A or ID_B in the application database.

• Since ID_A doesn't change, I can save myself call #3 each time if I grab it from the local DB during call #2.
• Since ID_B changes so rarely, I could also keep that in the local DB to save call #4.
• If I ever get a bad response from call #5 with the ID_B in my database, I could try call #4 and see if the ID_B has been updated.

Option 2

Another option I'm more or less ruled out is storing ID_A/ID_B in my Identity Authentication Service. I can add a few user attributes and get them back with the initial check at call #1, but if we add more applications in the future that make use of the same Identity Authentication Service, and may use Authorization Service A, B, or C & D, I think that's starting to be a mess in the Identity Service.

Question

Would it would make logical or good architecture sense to store the IDs from service A and B in my application database? It would certainly work, but is this a bad design decision? Should I just make those calls every time? Or is there someplace else I should be saving/caching those IDs?

Answer 1

Why do you think calling those services would be a problem? I mentioned the complexity in my comment, but I have an impression that something else bothers you. If it's performance, first implement the simple solution, and see how it performs. If all the services are within the same data center, you may be surprised to see how fast this thing is.

Otherwise, use cache. Since you know that the data may not change frequently, caching the responses of the different APIs seem a good idea if there are noticeable performance issues from those multiple calls. Existent solutions to integrate cache when doing HTTP requests should make it relatively simple to add one to an existential project later.

Don't use a database, since it will create a second source of truth. In a case of a database, you'll probably end up with an overly complex, hand-made approach, which would be difficult to understand to the newcomers.