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:
- Check a username & password with our Identity Authentication Service.
- Look in our local database for the user's preferences related to the app.
- Send username to Authorization Service A, get back ID_A.
- Send ID_A to Authorization Service B, get back ID_B.
- 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.
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.
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?