Auth (-entication) and (-orization) in blockchain

Blockchains are public ledgers that individuals use to create, store, and move value in the open, and devising methods to ensure security is critical for their use in the real world. Several security mechanisms exist in blockchain technology, but the details and implementations can vary between various networks.

Two such mechanisms are authentication and authorization, which are similar concepts and are often used interchangeably but actually mean different things. Authentication answers the question: “Are you who you claim to be?” while authorization answers the question: “What are you allowed to do?”. Both work together to verify identities, control access based on those identities, and leverage various blockchain features, such as smart contracts and digital signatures, to manage and enforce those controls.

Let’s say you’re headed out for a night of karaoke at a 21+ bar. You flash your ID to get in (authentication, the bouncer checks your ID’s photo to verify that you are who you claim to be). Once inside and a couple of drinks deep, you decide to sing “I Want It That Way” by Backstreet Boys, and you bring this request to the host. Unfortunately, the host has decided that the only song anyone can sing for that night is “Margaritaville” by Jimmy Buffett, and your request is denied (authorization, you’ve been authenticated, but you can’t sing your chosen tune based on the host’s rules).

As seen from this example, authentication determines whether someone is who they say they are, while authorization determines whether they can perform a specific action. Together, authentication and authorization in blockchain help ensure security and user control while also enforcing decentralization.

The Stellar blockchain has handled authentication and authorization with signature weights, multisig, and thresholds, but with the introduction of smart contracts, these methods can become more flexible and complex. Let’s get into some auth (-entication) and (-orization) basics and what this looks like on Stellar and Soroban.

Identity verification in blockchain typically uses digital signatures with cryptographic keypairs. A keypair consists of two keys: a public key and a private key, which are generated as a pair using cryptographic algorithms like the Rivest–Shamir–Adleman (RSA) signature scheme or Elliptic Curve Cryptography (ECC) (Stellar uses the Ed25519 signature scheme, which is a type of ECC). These cryptographic algorithms ensure that a private key and its corresponding public key are mathematically linked.

To generate a keypair, the private key is created first using a random number generator. The public key is then derived from the private key based on the cryptographic algorithm used (like ECC, mentioned above — if you’re interested in the mathematics behind ECC, check out this article that explains it in detail). This key generation process is a one-way function, meaning it’s computationally feasible to generate the public key from the private key but practically impossible to derive the private key from the public key. A public key is shared with others to receive and send transactions, while a private key should always be kept secret.

Users sign blockchain transactions with their private key, creating a digital signature unique to the transaction and the private key used. When the transaction is broadcast to the network, nodes run the signature and public key through an algorithm to verify the digital signature was produced by the private key. A digital signature is also a one-way function — a user can never derive a private key from the digital signature.

Once authentication is complete, authorization determines access control or what kind of privileges a user has. Outside of smart contracts on Stellar, users control what can be done using signature weights, multisig, and thresholds. Every Stellar operation has a static threshold category (either low, medium, or high) that is hardwired in the Stellar Core code, and an account assigns each threshold category a number between 0 and 255. This threshold determines what signature weight is needed to authorize an operation. Accounts also set their own signature weights and additional signing keys. To determine if a transaction has the necessary authorization to run, the weights of all the signatures in the transaction are added up, and if the sum is greater than or equal to the thresholds for the operations, then the transaction is authorized to go through.

So, for example, if an account sets its medium threshold weight to 5, its master signature weight to 3, and Account 2’s signature weight to 2, a transaction with the change_trust (medium threshold) operation must have signature weights that are greater than or equal to 5 — so with using multisig, the signature from the master account and Account 2 can authorize the transaction.

Although this scenario does grant some flexibility, authentication and authorization rules in smart contracts can do more to automate and enforce identity verification and access controls — contract writers can define much more complex logic that allows for methods and mechanisms adaptable to a wide range of scenarios.

Now that we’ve got some basics down, we, of course, need to talk about authorization on Soroban, the smart contract platform on Stellar. Soroban’s authorization framework is built into the core protocol, meaning custom contract-specific authentication can be implemented without the need for protocol-level changes. Soroban’s authorization has built-in implementations for standard features, such as signature verification and replay attack prevention, the latter of which helps reduce the probability of bugs, while also providing a framework for more complicated and customizable authentication and authorization rules.

One notable feature of Soroban’s authorization framework includes account abstraction, which is a way to implement contracts that perform custom authentication and authorization.

Let’s get into it.

Soroban supports regular or “classic” Stellar accounts (represented by a G address) and smart contract accounts (also called custom accounts, represented by a C address)— every account, whether a “classic” Stellar account or contract account, is represented by an Address when interacting within Soroban, which allows for interoperability across systems.

Although they are represented in the same way, authentication is handled differently for each type of account. “Classic” Stellar accounts are authenticated in the typical way explained above: with multisig, signature weights, and thresholds. However, smart contract accounts have much more flexibility when it comes to auth and can write custom authentication and authorization logic (including multisig, web authentication, mobile authentication, and more) into their contracts thanks to account abstraction.

By definition, account abstraction lets users use smart contracts as accounts and allows them to interact with other contracts even with differing auth logic.

I’ll provide a simple example of how this works:

• Let’s say that the token contract for FINE token has implemented an authorization rule where a token transfer from User A to User B must be authorized by User A.
• Contract Account A (User A) is attempting to send 5 FINE tokens to another account (User B) using the FINE token contract.
• The Soroban host recognizes that authorization is required to perform this action.
• Contract Account A has custom authentication logic written into it that says it is allowed to perform this action with a WebAuthn signature from itself and also includes authorization rules stating that any transfer or allowance is limited by at most 10 FINE tokens.
• With the WebAuthn signature and confirmation that this action won’t transfer more than 10 FINE tokens, the action is authorized.
• The FINE token contract recognizes that the action is authorized, accepts it, and the transaction is executed.

In this case, the FINE token contract has no idea how the action was authenticated, it only recognized that it was authenticated. This ability enables contract writers to create custom, contract-specific authentication logic compatible with other contracts’ generic authorization rules.

With account abstraction built into Soroban’s authorization framework, contracts written now will be compatible with contracts written far in the future with new authentication methods that are still being developed, such as post-quantum cryptography.

Soroban’s authorization framework and the introduction of contract accounts facilitate increased expressiveness through fine-grained transaction construction. Developers can build custom authorization capabilities into their contracts that require approval for individual actions for multiple parties, not just the contract invoker. These fine-grained authorization capabilities help developers tailor their contracts to fit their specific needs and allow for the creation of more dynamic applications.

In addition, when constructing a contract call, it can be difficult to determine the resource fee (which includes read/writes, CPU, etc.) and the authorization needed for it to execute. To help with this, Soroban provides a simulation endpoint that trial runs the transaction against a temporary snapshot of the ledger, creating a transaction footprint that tells the user the estimated fee and authorization needed for the transaction to execute.

Being able to estimate the resource fee amount and signatures needed for a transaction to be successful before attempting to submit it to the network helps prevent failed transactions, as contracts can have required signatures nested deep within their construction that can be easy to miss.

The introduction of smart contracts on the Stellar network opens up massive opportunities for innovation on the blockchain. With Soroban’s authorization framework, developers can construct sophisticated and interoperable contracts with complex authentication and authorization logic. Following a successful validator vote on March 19th, Soroban is now in Phase 2 of its phased rollout launch, meaning it’s user-ready, and anyone can deploy and interact with smart contracts on the network. It’s an exciting time to be building on Stellar!

Get involved and stay up to date on all things Stellar and Soroban by joining the Stellar Developer Discord, where lively discussions are happening every day. You can also check out various proposals in GitHub, like CAP-51: Smart Contract Host Functionality: Secp256r1 Verification, where the Stellar ecosystem is exploring a new built-in signature verification mechanism for Soroban smart contracts that supports web auth and passkeys.