4.1 Introduction to Auth

Authorization is a fundamental concept that enables you to create more functional decentralized applications. It plays a pivotal role in blueprint design, prompting questions like 'Who has permission to perform specific actions?' Unlike Web2 applications, Web3 applications operate within a distributed ledger system. Moreover, applications built atop these distributed ledgers run on a shared computational environment. This inherent architecture renders them permissionless by default, which is why they are often referred to as decentralized applications (dApps). Consequently, by default, anyone can interact with these applications and invoke any public methods, which are then executed by smart contracts. While this openness is indeed a feature and not a flaw, there are cases where we need to restrict certain actions to specific entities

Let's delve into a decentralized application scenario involving index funds. In this context, we encounter two distinct types of users: Investors and Fund Managers. The actions available to Investors are relatively straightforward, primarily centered around the ability to deposit or redeem assets from the fund.On the other hand, Fund Managers bear a significant responsibility as stewards of the investors' funds. Their role entails determining how the deposited funds are invested and necessitates a secure mechanism for moving assets on behalf of the Investors. Establishing a robust authorization model is imperative here, as we must ensure that only authorized individuals can initiate fund movements. These authorization models are instrumental in empowering decentralized applications (dApps) with substantial capabilities. They enable us to create applications that are inherently inclusive, yet maintain precise controls over essential features. By defining authorization rules within your blueprint or for the resources you create, you gain the ability to restrict actions to a defined group of individuals.

With Scrypto, developers gain the ability to implement sophisticated, granular, and highly flexible authorization models for their decentralized applications (dApps). This capability stems from the Radix Engine's robust security model, which leverages an asset-oriented approach to provide authentication and authorization. Scrypto's authentication model revolves around three core concepts: roles, access rules, and badges. We will briefly explore each of these concepts and tie them together by the end of this chapter.

Authorization in Scrypto begins with the concept of roles. Roles are distinct labels, either predefined by the Radix Engine or defined by you. For example, when it comes to making your resource mintable, you’ve already seen that it comes with corresponding pre-defined roles such as a minter and a minter_updater. These roles represent the access it is permitted to have, therefore, can be seen as a way to delineate the boundaries between access controls.

If roles serve as the boundaries for access control, AccessRules play a pivotal role in defining the specific conditions that must be fulfilled for a role to be accessed, along with its associated permissions. Essentially, these conditions are represented by badges that need to be met. For instance, you can specify that the minter role of a resource must possess a corresponding "minter badge" before it can mint additional supply of that resource. In general, roles are coupled with their respective access rules to determine which badges individuals holding those roles must possess to access permissive methods and actions. AccessRules offer a versatile array of conditional statements that you can mix and match to fulfill the requirements for role-based access, ensuring a fine-tuned and secure authorization system.

These badges can take the form of either fungible or non-fungible resource types, each offering unique advantages depending on your specific use case. Specified within an AccessRule to control access to particular actions, badges must be present before the corresponding action can be executed.

Together, these concept form a role-based authorization model which offer clarity to delineate who has permission to perform specific actions through roles, AccessRules to create conditions required to access a role, and badges to tangibly prove that you can access a role. This model shifts the focus from 'who you are' to 'what you own,' unlocking numerous advantages for building comprehensible yet sophisticated authorization systems: