In my work we've been tasked with implementing two factor authentication across a number of our web applications which currently share a credentials database (asp.net forms authentication) but have their own code for collecting and validating credentials etc.
In thinking through this problem I've reasoned that this might be a good time to consolidate all our authentication into one web service (FWIW I'm looking at IdentityServer) which all our various web applications could use.
To my mind this follows the DRY principle, will make implementing and testing the 2FA itself easier, and lead to a more maintainable system in the future. However in discussing my plan with a colleague he has suggested that I'm introducing a single point of failure to the system, and that if a bug were introduced to the Authentication service it would bring all our applications down. To be clear we're not talking about service availability (The service would be hosted with the same level of resilient infrastructure as our other applications which my colleague accepts as reasonable), but about the potential of a single bug to take down all our applications. His suggestion is that we either write the authentication into the individual applications or we should provide some sort of redundant auth system for if the primary system fails.
To me this argument just feels the wrong way round. If we're depending on different implementations to stop all our services failing then we're doing it wrong. However I've been unable to put a convincing case to make colleague. Some of the arguments I've put forward:
- This is no different to using libraries between projects - If a critical bug in some of these libraries were to reach production it could take down a number of our applications - but we're not suggesting that we shouldn't be sharing code here. Is this conceptually any different?
- Whilst there is room for improvement we don't have a terrible testing/deployment process. We use continuous integration, we have automated unit tests, a reasonable test environment and manual test scripts (not to mention the ability to revert a production deployment if we do get a bug through). Whilst bugs are always going to get through, this process is the mitigation against that, not writing things twice.
- By its nature the authentication process is not the sort of thing that's going to be undergoing major changes regularly. Once we have an authentication system that works we're likely to leave it be, making the risk of breaking anything fairly low.
- The DRY principle - Isn't writing the same thing multiple times more likely to lead to bugs and be a nightmare to maintain than having one service?
- The idea of a redundant authentication implementation is pretty crazy to me. Maybe if we were writing autopilot software for an airliner, but not for non safety critical web applications.
My colleague remains unconvinced. Am I wrong? If I'm not, what is the killer argument that I'm missing here?