4.5 Component Auth - Approaches to Auth

When it comes to component auth, we should be aware that there are two approaches we can consider: system-level auth and application-level auth. The use of system-level auth uses the same core concepts of auth in Scrypto: badges, AccessRules, and roles. Since these concepts are baked into the Radix Engine, developers can confidently leverage the Radix Engine to perform validations and protect permissions setup in their dApp. Application-level auth, while it still uses concepts of badges, it differs where custom validation logic written by the developer are performed within the component instead of by the Radix Engine. This employs the use of proofs passed directly into the component (as opposed to being sent directly to the AuthZone) and creating a combination of assertions against the proof sent in and any other data the proof may provide.

Generally, we recommend the use of system-level auth approach because not only does it provide guarantees of the Radix Engine, but also provides transparency to the users. The concept of badges, AccessRules, and roles are so deeply embedded by the engine that auth configuration can be revealed to the users to inform them and provide better user experience. However, there are nuanced cases of auth requirements where custom written validations performed at the application-level are needed. In which case, this is an option left to the developers to explore. So let’s go over both approaches.

First, when it comes to component auth, roles are defined by you. This is quite different from resource auth as resource behavior are accompanied by their pre-defined roles. We’ll get into that more later. Roles are defined by you to define whatever roles that suits the needs of your component. As mentioned before, your component may require something like a three-tier hierarchy system where you might need an “admin”, “super admin”, and a component owner role. When roles are defined in a blueprint, once a component is instantiated from that blueprint, those auth rules are configured to the Radix Engine to be enforced. This is powerful as the Radix Engine is designed with a Finite State Machine to enforce strict resource management. Therefore, without having to consider potential edge-cases that may arise when building our own auth system, the Radix Engine can enforce the rules we create around our components. After we’ve assigned roles to our component, the Radix Engine can use the proofs in the AuthZone and compare it against the role’s AccessRules.

While every proof is automatically sent to the AuthZone, we are not confined to authenticating proofs in the AuthZone. Instead, we can pop proofs from the AuthZone and instead pass it directly to component method(s) to perform custom validation within the component. This way of applying application-level authentication is called Passing Proofs by Intent. Arguably, Passing Proofs by Intent can be more flexible than system-level auth as we can define our own custom auth logic within the blueprint. This is because when we are sending non-fungible proofs directly to our component method(s) the component can read and utilize the non-fungible proof’s NonFungibleData.