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.

Application calls to external services

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.


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?

  • You may want to consider simplifying the whole thing. Complex systems are usually less secure, since there are more ways to introduce vulnerabilities in them. Would it really matter how you store/cache the IDs the day your system is hacked?... Aug 16, 2018 at 17:17
  • Is it really all that complex? We've got a few services provided by external vendors. IMO, having a provider for Identity Authentication is more secure. We pay them to maintain their login system, and we don't need to implement logins - undifferentiated heavy lifting. As for Services A & B, A does a lot of stuff for us, and B is almost like a plugin for A, adding a little extra functionality that A doesn't have on its own. None of the services provided by A or B are core competencies for us, but we use them to help us deliver our core competencies in our application. Aug 16, 2018 at 18:13
  • Looking at the diagram and reading your question, I am easily lost, especially for the part where there are two authorization services (I would expect a maximum of one) and that one of them is called twice. Authentication and authorization are better to be abstracted by a library/framework where you call a method at some place, and you get a response somewhere else. The part where you create and sign a token is, IMO, the scariest. Definitely something I'll leave to a third party, heavily reviewed library. Aug 17, 2018 at 7:48

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.