An alternative approach to providing identity infrastructure for your applications is to use a cloud-based identity service. There are a number of different service providers out there including the big cloud application development platforms such as Microsoft’s Azure Active Directory, Google, and Salesforce and smaller specialist identity as a service (IDaaS) providers like Okta, Ping, and Onelogin.
Using a hosted service has a number of advantages over building your own identity system. Such services are generally well designed and implemented, they support common identity standards, provide a robust, reliable and scalable service and they are ‘just there’. You don’t have to manage any additional cloud infrastructure to support your application’s identity needs.
However, there are some significant downsides to using such service providers. First, you lose control of your identity information. Instead of storing sensitive identity data on servers that you control and administer, you store it on servers controlled by a third party. This might not be a big deal. The public identity services may very well have stronger security controls and administration processes than you do. But your legal or security requirements may prohibit letting sensitive identity information out of your control, or allowing it to be handled by a foreign enterprise subject to a foreign government’s privacy and disclosure rules.
Another potential problem with public cloud identity services is their relative inflexibility. These providers have created infrastructure capable of supporting identity on a large scale, but they have traded off features and configurability that might be important for your applications. For instance, some identity services provide only a fixed identity schema. If you need to store additional attributes with your identity data, you must implement your own parallel identity store.
However, the real problem with committing to a public identity service is vendor lock-in. Once you have stored all your identity data with a particular service and written your applications to work with the particular features and quirks of that vendor’s system, it will be very difficult to move your application to a different identity infrastructure. You have effectively locked your applications to the vendor’s identity infrastructure and you will be subject to whatever service, feature, and cost changes that vendor decides to make in the future. So, while you enjoyed agility at the start of your project by leveraging an existing service, you have basically given up that agility for the life of your application.