How GDPR is Forcing the Tech Industry to Rethink Identity Management & Authentication
Identity management and authentication have been a hot topic in the tech community for decades, and the passing of the General Data Protection Regulation (GDPR) last year only exacerbated the discussion. Judging by current moods, matters may get worse if the U.S. agrees to throw its hat in the game and start regulating data privacy. It may only be a matter of time, given that many U.S. tech companies, including players like Microsoft, are now calling for Congress to take action and embrace data privacy with a passing of its own version of GDPR. Companies providing services to European citizens are heavily affected by the new law and are still scrambling to be compliant, despite spending unprecedented resources to do so. There are already lawsuits filed against some of the tech giants, including Google and Facebook, and if the U.S. passes its own version of GDPR, we’ll see many more companies being sued, thus trickling down implications throughout the tech space.
I can’t help but think that all of this could have been avoided if tech companies had taken data privacy management more seriously and had made it a higher priority from the very early stages of their product development.
But first things first — let’s discuss the difference between identity management and authentication. A lot of service providers don’t really understand the difference and put these two into the same bucket. This causes maintenance nightmares for a product down the road, especially when laws like GDPR are introduced.
Identity management is the act of securely storing an individual’s or organization’s personally identifiable data. That’s it. The identity manager must also provide a way for this data to be accessed, transferred, modified, deleted, or acted upon by the owner (individual or organization representative).
Authentication is the process of verifying the identity of a user against an existing identity management database. Once a user is authenticated, the system can then authorize that same user and give proper permission to access resources that he/she is entitled to based on their identity attributes.
Currently authentication can happen in one of three ways:
- Something you know — e.g. username/password combination
- Something you own — e.g. a cell phone can get a text or temporary code
- Something you are — e.g. biometric authentication, thumbprint, retina scan, etc.
There’s really no other way to authenticate against a database, at least with current available technologies. The most used form of authentication is “something you know”, setting up a username and password.
If you do a quick search on identity management you will see a number of definitions. Most of them will be misleading. This is because they include authentication, access management, tokens, etc., as part of the definition. This is unfortunate. Authentication, which encompasses access management, authorization, keys, tokens, sessions, etc., is very different than identity management. In fact, they are so different that the identity management database can be a different system altogether. For example, the Social Security Administration has an identity database of all entities that have a social security number or entity tax ID (in the case of a company). The SSA manages these identities separately, and it has done so for years, way before there was any form of online authentication. The authentication process was introduced later for ease of online access.
Now that we have a clearly defined difference between identity management and authentication, it’s easy to architect a product to be malleable enough and to be able to withstand any regulatory rules governments institute.
The state of identity management should ultimately be standardized, if it is to be as close to ideal as possible. There should be a central “hub” where any vetted service can connect to for a database of identities to authenticate against. A centralized system that holds all identities would also enable users to have one identity for all services, allowing them to be logged in everywhere with a single username and password combination.
This will most likely not happen, however, for two main reasons:
1. Security. A single database is prone to attacks, any breaches in this database would be disastrous. The hackers would gain access to all users on the Internet. This downside could be mitigated through blockchain technology, but it has to be done carefully.
2. Not everyone is willing to be part of one single identity management database. It would be difficult for everyone to accept this standardization as many would see it as a breach of personal rights. The SSA, in the example above, has a version of a central identity database, but this is out of necessity and, of course, because it’s mandated by law. I doubt and would be very surprised if the same would be done for an identity management service database.
Currently the closest infrastructure to having such a single central identity hub in place is the Single-Sign-On (SSO) Federation with a federated identity that can be used across multiple systems that are part of the federation.
Having worked with federated authentication for many years, I don’t believe that this standard is good enough to be embraced globally, especially when taking into consideration some of its limitations. Some of its ideas and basic groundwork are good, but the SSO Federation has a long way to go before it’s fully accepted in the tech industry. Federated SSO is useful for some organizations, mainly higher ed, libraries, NGOs, but it must be improved upon because, in its purest form, it’s inadequate for use in commercial tech products where real-time identity updates across all systems are a must.
Since a single identity management hub seems to not be feasible, the next best thing to do is to modularize the identity management and authentication pieces within the product. This way you can integrate to other identity databases or authentication services (e.g. Facebook, LinkedIn, Google, etc.) as needed, allowing users to use an existing account they might access on a daily basis.
Authentication is a central piece of any software product. This is the way it should be. Any user would have to authenticate before using the product. However, there’s no need to have the authentication and identity management pieces so tightly knitted within the product. They can be their own entities, modularized to a point where the interfaces are so well defined that they can be replaced at any time. Even better, add other identity databases or allow for authentication using popular social networks.
Product owners must modularize to a point where they create their own standardized version of identity management for their specific service/product. Doing so will make it easy to modify implemented modules to comply with GDPR requirements (most notably anonymization — anonymizing user data upon request, and communication — sending emails only upon explicit opt-in, otherwise the user must be opted-out) or any other requirements future governments might enact.
