This article was available first on The New Stack - read it here.

Authentication and authorization often go hand in hand, but increasingly, that’s not the case in modern software architectures. Authentication is where users prove their identity, while authorization defines what they can do inside the system - separating them allows you to take deeper control of both.

The recent trend of separating these two components - dubbed Bring Your Own Identity (BYOI) by Gartner - is gaining traction and comes with a number of benefits.

In this article, you’ll learn more about the opportunities that are created when authentication is handled for you and how to take advantage of them.

What Is BYOI and Why Do You Need It

BYOI is an approach to authentication that lets users verify their identity via third-party services. If you’ve signed in to a website or application using your Google, Apple, or Facebook credentials, you’re already familiar with it.

This approach to authentication is becoming more popular because of the benefits it offers both users and developers.

One Less Password

By embracing BYOI and supporting many providers, users can log in with the credentials they already have rather than having to create a new username and password just for your service. With the proliferation of online services we all use, password fatigue is real, and letting users just authenticate with an existing service removes one more password from the list to remember.

Better Security

One of the key benefits of BYOI is that it lets you use a service with a higher level of security or user trust than you can currently offer. That can be a particular issue for new startups, with whom users might not want to share all their data.

Using another service, like Google, Apple or Facebook, can ease those anxieties and allows you to benefit from all the security features they offer. There are also many government-verified identity services in Europe that let your users prove who they are.

Enables Decoupled Authorization

If you’re stuck using an existing ecosystem, like Django, Ruby-on-Rails, or Larvel, where authentication and authorization are coupled together, it’s hard to go beyond what they offer. You can rewrite what’s there, but that requires a heavy time investment.

With BYOI, authentication is handled for you, so your focus can be on the actual business logic of authorization, and importantly you can choose a solution that includes the precise features you want and matches your needs in areas like security and compliance.

That flexibility also means you can swap out or evolve either area independently - such as supporting a new identity provider or changing how a role is defined, which is faster and has benefits for scaling.

What BYOI Means for Authorization

BYOI is a paradigm shift in how authentication and authorization work together - it means identity is being handled by a 3rd party and authorization is now decoupled from the user's identity source and thus can go beyond the basic roles of typical user management systems.

How authorization decisions are made doesn’t change much with BYOI - you still have to determine who gets access to what resource and decide how that information can be modified and used - but the interaction between authentication and authorization does.

Multiple Provider Modeling

As the user's identity is coming from any number of providers, the system needs to be able to ingest the user's profile from any of them. You then need to take the identification data you get in a token or a callback and map the various profile attributes and account data from each source into a standardized model which can then be used for making authorization decisions.

Handling this disparity whilst giving users the flexibility to use any identity source is part of the challenge. Yet, it’s essential if you want to take full advantage of the benefits of BYOI as there is rich information and context in a user's profile that can be of use in authorization logic.

The Complexity of Roles and Permissions

Previously, it was easy to determine roles and permissions, as they were likely stored in the same database entry as the user's credentials and would cover a simple service. Credentials could be mapped to permissions on a simple one-to-one basis.

The picture is now more complicated as the business logic around who can do what in a system now needs to be decoupled from any particular identity source.

As the information about the user will vary based on the identity source, even when mapped into your standardized model, any authorization logic needs to handle the case with partial or missing attributes that before may have existed in your own user management system.

This means that the role and permission are no longer a static set of values for each user, but need to be computed on the fly based on the identity data provided, and more often these days also by attributes of the resource the user is trying to interact with.

Rather than hardcoding this logic once again, given you likely will want to support more identity providers in the future, now is a good time to implement an architecture that allows you to encapsulate and separate out authorization logic into its own service which can handle the dynamic identity information.

You could build this yourself in-house, but one alternative is the open source project Cerbos, which can help you take advantage of the separation of concerns that BYOI demands. As authorization checks can accept an arbitrary set of attributes about the user (or principal in Cerbos speak), it is a perfect match for when the user identity may be from a number of different providers.

Inside the authorization policies, conditional logic can then be defined to check certain attributes from the user's identity along with the resource they are trying to access, as well as handle cases where the particular identity source being used may be missing certain data points. This is a far more scalable approach when the identity information is going to be dynamic and evolving over time as you onboard new providers.

Conclusion

Authorization and authentication used to go together like bread and butter. Modern paradigms, like BYOI, have now changed how user identities are handled inside an application.

BYOI for users means one less set of credentials to remember and manage, and they can feel safe using their trusted identity provider to authenticate with your application.

For developers, BYOI forces a decoupling of authentication and authorization and opens the door to picking the best solutions for both components, including leveraging open-source projects that ensure you are not reinventing the wheel and allow you to focus more on delivering on your core value.