Authorization is the process of giving someone the ability to access a resource.

Of course, this definition may sound obscure, but many situations in real life can help illustrate what authorization means so that you can apply those concepts to computer systems.

A good example is house ownership. The owner has full access rights to the property (the resource) but can grant other people the right to access it. You say that the owner authorizes people to access it. This simple example allows us to introduce a few concepts in the authorization context.

For instance, accessing the house is a permission, that is, an action that you can perform on a resource. Other permissions on the house may be furnishing it, cleaning it, repair it, etc.

A permission becomes a privilege (or right) when it is assigned to someone. So, if you assign permission to furnish your house to your interior decorator, you are granting them that privilege.

On the other hand, the decorator may ask for permission to furnish your house. In this case, the requested permission is a scope, that is, the action that the decorator would like to perform at your house

Sometimes authorization is somewhat related to identity. Think of the process of boarding a plane. You have your boarding pass that states you are authorized to fly with that plane. However, it is not enough for the gate agent to let you get on board. You also need your passport stating your identity. In this case, the gate agent compares the name on the passport with the name on the boarding pass and let you go through if they match.

In the authorization context, your name is an attribute of your identity. Other attributes are your age, your language, your credit card, and anything else relevant in a specific scenario.

Your name written on the passport is a claim, that is, a declaration stating you've got that attribute. Someone reading your name on your passport can be sure of your name because they trust the government that issued your passport.

The boarding pass, along with the proof of identity of consumers, represents a kind of ‘access token’ that grants access rights to jump onto the plane.

In the scenarios described above, you can see that the act of authorizing enables entities to execute tasks that other entities are not allowed to complete.

Computer systems that use authorization work in a similar manner.

In computer systems, authorization rules are part of an IT discipline called Identity and Access Management (IAM). Within IAM, authorization and authentication help system managers to control who has access to system resources and set client privileges. The way that IT systems deal with authorization services is very similar to a real-world access control process.

Consider a collaboration tool like Google Docs.

The application allows you to create and share documents. Other permissions include being able to update, delete, comment on a document. If you are the owner of a document, you can share it with someone else and define one or more access policies. For example, you can share your document with someone by letting them just add comments.

In this scenario:

Resource: it’s the document

Resource Owner: this is the user that creates a document, the owner of the document

Authorized User: the user who is given comment rights by the Resource Owner

The following diagram represents the authorization to resource access:

There are several different authorization strategies that computer systems leverage during application deployment. The most prominent ones are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Recently, Auth0 has been investigating and solving for Relationship Based Access Control (ReBAC). There are multiple other alternatives, including Graph-Based Access Control (GBAC) and Discretionary Access Control (DAC). Each one of these strategies will help application developers deal with different authorization requirements and authorization services.

When using ABAC, a computer system defines whether a user has sufficient access privileges to execute an action based on a trait (attribute or claim) associated with that user. An example use case of this authorization process is an online store that sells alcoholic beverages. A user of the online store needs to register and provide proof of their age. In the authorization context, this scenario can be described as follows:

• The online store is the resource owner

• The alcoholic beverage is the resource

• The age of the consumer validated during the registration process is a claim, that is the proof of the user’s age attribute

Presenting the age claim allows the store to process access requests to buy alcohol. So, in this case, the decision to grant access to the resource is made upon the user attribute.

RBAC, on the other hand, treats authorization as permissions associated with roles and not directly with users. A role is nothing but a collection of permissions. For example, imagine that you work as a department manager in an organization. In this situation, you should have permissions that reflect your role, for example, the ability to approve vacation requests and expense requests, assign tasks, and so on. To grant these permissions, a system manager would first create a role called "Manager" (or similar). Then, they would assign these permissions to this role and would associate you with the "Manager" role. Of course, other users that need the same set of permissions can be associated with that role.

The advantage of using RBAC is that managing authorization privileges becomes easier because system managers can deal with users and permissions in bulk instead of having to deal with them one by one.

Relationship Based Access Control examines the following question in regards to authorization: “Does this user have a sufficient relationship to this object or action such that they can access it?” The relationship can come via a user attribute, such as being a member of a role group related to the object, or having a direct relationship, such as being shared on a document. Sometimes a traversal of a graph of groups, roles, organizations, and objects requires exploring many nodes to establish a relationship between a user and what they are trying to do. Which relationships are critical to gaining access and the permissions that those relationships grant is up to the implementer of the ReBAC system.

Auth0 has recently released a Developer Community Preview for our upcoming Auth0 Fine Grained Authorization product, based on ReBAC. You can learn more at our developer preview page for Fine Grained Authorization.

Keep reading at our Intro to IAM page to explore more topics around Identity and Access Management.