Editor's Note: This is the first, introductory post in a 3-part series on focusing on Authorization. Stay tuned for future parts in this series, technical posts focusing on RBAC/groups and dynamic authorization.
In the world of Identity and Access Management (IAM), there are generally two high-level concepts applications and middleware resources employ: authentication and authorization (AuthN and AuthZ).
The term authorization refers to a wide range of concepts within the IAM space but it essentially boils down to controlling what a user can do. The authentication process ensures that the individual making the request is actually who they say they are (i.e., their identity). Once a person’s identity is verified, the authorization process establishes which resources they have permission to access and in which manner they can use those resources.
"The term authorization refers to a wide range of concepts within the IAM space but it essentially boils down to controlling what a user can do."
Consider the experience of obtaining a passport to travel internationally. In this case, the issuing country requires applicants to complete paperwork and submit photographs to verify their identity. Once approved, the individual can book travel by using their passport to authenticate their identity. Airlines and trains rely on government-issued passports to give individuals boarding passes, which include detailed information about their trip. These passes authorize travelers to board flights and trains at assigned gates or platforms and at specified times.
Similarly, when a user logs into an application, they are required to authenticate their identity using, for example, a username and password. Upon the successful verification of these credentials, an authorization server tells the application who is trying to access it and what they are allowed to do using artifacts called tokens. Just like passports allow entry to an airport and boarding passes tell travelers which planes they can access (including what time to board, where they can sit, etc.), tokens control the level of access to an application or resource.
Controlling Access with Permissions, Roles, and Groups
In the passport example illustrated above, the application receives tokens that tell it pertinent information about the user including which resources she has permission to use. In a simple implementation, one could achieve access control by assigning permissions directly to users; however, this model (i.e., Discretionary Access Control) is difficult to scale with high user volume, when providing services to other businesses, or centralizing identity management (e.g., SSO for employees).
The concept of roles plays a crucial role in making it easier to manage user authorization. Roles are essentially a mechanism to group a set of permissions for assignment to users who require the same level of access to a given set of resources. For example, all cashiers at a grocery store need to perform the same tasks to do their job such as price lookup, bills of sale, receipt printing, etc. Rather than assigning or unassigning each permission to every point-of-sale employee, the grocery chain can create a role (e.g., cashier) and assign it the necessary permissions. When an employee changes position, the grocery chain only has to add or remove a role from the user. If the required permissions for a particular role changes, the admin only has to update a single role instead of having to update each user individually.
"Roles are essentially a mechanism to group a set of permissions for assignment to users who require the same level of access to a given set of resources."
The value of the roles-permissions model (i.e., Roles-Based Access Control) above is tremendous; however, when working with cross-functional user structures (e.g., employees), roles can be difficult to manage. Consider the various departments and teams that employees belong to and the permissions required for them to do their jobs. Mapping employees to all the roles they have and the specific permissions they need is burdensome and error-prone. This is where groups can help cut the effort required to manage on/offboarding and reduce errors with permission standardization.
Rather than assigning users specific roles, admins can assign users to groups that house a collection of roles and permissions. Referencing the example above, the grocery chain can create a group that includes the roles and permissions all employees need, and specific groups for each team and department. In the case of the cashier, she would initially only require access to the cashier role; however, as her tenure grows within the company and she gets promoted, admins can easily adjust her permissions by assigning her to the store manager group.
Maximizing the Power of Auth0 Rules
Every business has very specific needs that an out-of-the-box solution cannot typically solve. In the case of the grocery chain, what if an employee visited a store after work hours and attempted to sign into their account, or had not changed their password in ages? Perhaps there are specific attributes about the user (e.g., location) or relationships (e.g., employee-manager) that need to be dynamically checked to comply with business requirements. With rules, developers can select pre-made scripts or write custom snippets to solve virtually any access control problem. After a user’s credentials are verified by an identity provider, Auth0 rules execute and determine which resources the user should be able to access.
Want to take a deeper dive? Check out our authorization docs for the technical ins and outs.
Authorization Series - Pt 1: What is Authorization? - You are here
Auth0, the identity platform for application builders, provides thousands of customers in every market sector with the only identity solution they need for their web, mobile, IoT, and internal applications. Its extensible platform seamlessly authenticates and secures more than 2.5 billion logins per month, making it loved by developers and trusted by global enterprises. The company's U.S. headquarters in Bellevue, WA, and additional offices in Buenos Aires, London, Tokyo, and Sydney, support its global customers that are located in 70+ countries.