Authorization (AuthZ) and Authentication (AuthN): A Brief History

(Almost) Every. Major. Company. In. Identity. has written an article on the difference between authorization and authentication. To summarize: authentication is who you are, and authorization is what you can do. Your time is valuable (and we’re not interested in wasting it!), so this article will not spend much time defining the concepts and will dive into their history instead.

Authentication: From plaintext files to SSO

Initial attempts at authentication were password-based. Fernando Corbató implemented the first computer password in 1961 to secure users’ files on a shared MIT computer (stored via plaintext file… and yes, someone did find the file and print out all the passwords stored on the system). This basic scheme is still often used today; the iconic username:password combination has resulted in many a “lost password” frustration and various technologies implemented to obtain those passwords (see the xkcd comic below).

Today, we’ve augmented basic password authentication with Multi-Factor Authentication (MFA), which uses additional factors to supplement something you know, like a password. Some examples of these additional factors include biometrics, single-use codes sent by text message and email, and hardware-based keys (see: anyone who has spent minutes frantically searching for their phone to approve a Duo Push or Okta notification and/or the comic below). Following MFA was the widespread adoption of Single Sign-On (SSO), which concentrates the authentication task into the control of a handful of companies. The most familiar example is Google, where you can use your Google account to sign into many different websites without re-entering a unique username or password.

Authorization: Authentication’s oft-overlooked counterpart

The history of authorization is a bit more difficult to track due to how much we’ve focused on (and written about) trying to “solve” authentication. Even the Wikipedia article on authorization is a pretty quick read, and when we explicitly searched for the history of authorization on Google, the top four results still garnered accounts of authentication (see image below). Authorization is the more junior of the two in terms of standardization and development, and that’s why its history (as well as Crosswire and other authorization-focused enterprises) are where they are today. While authentication has had some records written about it, we’re still writing authorization’s history.

One of the most prominent early examples of authorization implemented in computers is thought to be the file system permissions of early Linux in the 1990s. The model included a basic (but effective) scheme where the file owner, users in the file’s group, and outside users could receive three different permissions: read, write, and execute. This scheme is still in use today by Unix-like operating systems and often takes the form of some variation of read/view, write/edit, and execute/run or comment permissions.

As the world became more Internet-focused, we saw web applications with complex permissions systems. For example, you can’t edit someone else’s Instagram post from your account and certainly can’t view the bank account balance of someone who hasn’t added you. The importance of maintaining these permissions while also making them easy to use was a question everyone was trying to solve, and the main piece of technology that emerged for authorization was OAuth (technically OAuth2.0, but we’ll colloquially refer to it as OAuth, see comic below). This protocol created a way for people to allow applications to have specific permissions (called scopes) on their behalf, granting access to information without giving them their sensitive information (i.e., passwords).

However, OAuth couldn’t fully answer the permission-maintenance question internally, and RBAC (Role-Based Access Control) became the latest authorization approach, used to control access based on the roles of users within an organization. RBAC allows administrators to assign users roles and permissions based on their profiles and job responsibilities and is used in many modern, multi-user operating systems today. However, as we expressed in our blog post “Why RBAC is obsolete,” “where roles were once able to be clearly defined and mapped between each other, modern companies face a tangled mess of permissions and access that are impossible to manage.” Therefore, RBAC causes security departments and business units to spend excessive time granting and auditing permissions once roles (that may have been discrete and useful previously) become outdated and irrelevant, making RBAC nearly impossible to scale efficiently.

The reason it’s so difficult for traditional authorization methods to scale up as organizations develop (what we’re calling authorization’s “scalability problem”) is that these methods require manual input for each user. Accordingly, as the number of users and roles in an organization increases — and as job responsibilities no longer fall into these conventional, discrete roles — this automatically increases the amount of work you must do to keep your authorization measures relevant. This is especially challenging when dealing with fast-paced, dynamic work environments or applications that utilize multiple clouds.

So, where does this leave the future of authorization?

In trying to solve the scalability problem, some organizations have stuck to manually updating every role’s permissions, while others have turned to different identity and access management (IAM) platforms to manage their authorization. IAM platforms allow companies to control who has access to what, all on a single dashboard, making it easier to view and implement security authorization at scale.

Regardless of the method, in order to adapt, authorization must solve the scalability problem. We believe that modern authorization-focused enterprise security companies like Crosswire should lead the charge. Where other authorization processes have become cumbersome and time-consuming, products like Crosswire’s automate the process within minutes. Crosswire gathers permissions across different enterprise applications to implement rule-based access without human intervention. Our engine automatically provisions access and identifies anomalies, providing the infrastructure to manage authorization at scale.

We’re entering a new chapter in the history of authorization. To help write this history, explore our career opportunities here and stay updated with our latest news delivered directly to your inbox below!