Solving Problems with Modern Identity

by Abhishek Hingnikar

In 2013, I was a young developer still learning best practices and architecture, and I found myself working for an exciting company where we wanted to simplify picture browsing for users by allowing them to access their pictures from different social media accounts. Much of this was made possible by something I had never used before. It all sounded simple enough at first. Each user had several accounts on multiple 3rd party applications. They’d login with all of the accounts, and we’d access their pictures. However, with a deeper look at this, there were several challenges on implementing this:

  • How do we get access to the API on the user's behalf?
  • How do we keep our liability low by keeping this access to read only?
  • How can we do this in a way that allows us to inject some extra business logic here?

For the first question, just storing the user’s credentials may sound like the perfect idea: the user enters their service credentials in your account and you can call the APIs on their behalf, or better yet, you can just login and impersonate the user on the service.

However, this very notion is extremely scary. The security model of a password relies around secrecy. Ideally, the only entity that should know the user’s password is the user and the service should be able to verify it. No other entities should have access to this. By asking the user to share their service password with us we’d be breaking this fundamental security model for a password. We’d also increase our liability because we are now, for all intents and purposes, indiscernible from the user.

As an added drawback of this opaqueness, the service provider can also not enforce any constraints on our access, nor can the user revoke this access without having to change their password. This highlights another problem with our approach. Namely, how would the user change their password if every service needed it? They’d have to change their password with every single service they want to be able to use this account. While I was going through this and many other challenges of building this access service,
my boss recommended I implement something called OAuth2, which claimed to solve all of these problems. He added something called an “access token”, and sent me a link to the API Doc to implement this. I was still confused how all of this correlates, and most importantly, how all of this associates to sign-in. 

Around the time of this experience is when I came across Cloud Identity, and this blog post that helped shed light on this landscape. I went ahead and implemented a fairly sophisticated system, one with all the bells and whistles of account linking and tokens. I wish someone told them python existed, just like passport.js existed for node. There was a lot of research and effort put into something that seemed like a fairly simple idea at first, and I was the sole person responsible for building it, with all the challenges, issues, &
responsibility associated.

Years later I found myself employed by Auth0, an identity provider as a service, and had the pleasure of working with Yvonne Wilson, my first manager at Auth0 and co-author of Solving Identity Management in Modern Applications. I also had the privilege of worknig with Jared Hanson, the author of passport.js, and the author of that very post that introduced me to the world of identity, and Vittorio Bertoccci—all of whom have contributed towards expanding my understanding of the space as well as identity in general.

Over the course of our combined years in the identity industry, Yvonne and I helped customers in several roles. In our combined experience we have noticed that organizations face similar challenges when applying identity to their own diverse set of needs. We believe that there are two major causes for this:

  • Tying identity management to business models
  • Lack of a starting point or well-organized path to learn about identity

Many developers and architects we worked with consider identity management as a part of their application within the constraints of their business model. This creates a problem. If you consider a user’s identity only within the scope of your app, you tend to make
trade-offs that limit capabilities. Let’s take an example of federation; i.e., the ability to share the single user in multiple applications. Most apps today have a support forum, a helpdesk, and a docs page alongside the core product. If you build the username password login form right into your product, it becomes increasingly hard for the other applications to share this user. The result is a separate forum user, helpdesk user, and product user, which leads to a bad experience for everyone.

Instead, if you build logins as an abstract component from the start, which can be used by all applications that share the user, adding a new app is rather simple and you have a single source of truth for identity data. There are well documented standards like OAuth, OIDC, and SAML that enable federation of a user from one app to others. When starting an application, these best practices are often not readily available. Simply put, there is no right way to do identity built into the application development life-cycle. In the application life cycle, it is often seen as overkill in the early days. Over the course of years, however, it becomes tech-debt that limits the ability to grow and innovate.

In summary, identity needs to be a component independent of your application’s architecture. If so, what would one need to know to get started in the right direction? What are the components of a good identity layer? Where can one read about usual and unusual requirements and bad practices? If I were to build an app or refactor an existing identity layer, where does one start?

While there are several resources that document OAuth 2.0, SAML, and later design decisions in great detail, we set out to write a primer of the identity management landscape. We hope you enjoy reading Solving Identity Management in Modern Applications and learning more about identity!

About the Author

Abhishek Hingnikar has enjoyed writing software from an early age and has worked on multiple startups during his career. He currently works as a pre-sales engineer at Auth0 where he helps customers architect federated identity management solutions using OIDC, SAML, WSFed, and OAuth.

This article was contributed by Abhishek Hingnikar, author of Solving Identity Management in Modern Applications.