Session Keys are the JWTs of Web3

Web3 UX today faces many challenges. High gas costs, long transaction times, and difficulties managing seed phrases are some of the most common issues that many projects, including ZeroDev, strive to fix.

However, there’s one problem that lies at the heart of why Web3 just “doesn’t feel right” to regular users, and yet is rarely discussed. The problem is that authorization is broken on Web3.

Authentication vs Authorization

Before we delve deeper, let's clarify the difference between authentication and authorization:

• Authentication is the process of proving who you are (e.g., signing a message to prove ownership of a whitelisted wallet).
• Authorization, on the other hand, is proving what you can do (e.g., giving Uniswap "approval" to spend your tokens).

Authorization on Web2

In Web2, authorization is usually managed with JSON Web Tokens (JWTs), primarily in the context of OAuth.

Consider logging into Zoom using Google. An OAuth sequence prompts you to grant certain permissions, such as creating calendar events. Once approved, Google generates a JWT containing these specific authorizations. The JWT allows Zoom to request services from Google's API on your behalf (e.g., calendar event creation), but nothing else (e.g., accessing your emails).

This process is so commonplace that people seldom pause to think about it. However, when newcomers to Web3 start using DApps, they quickly realize a daunting issue — authorization in Web3 is fundamentally flawed.

Authorization is Broken on Web3

The central idea of the JWT experience is that on Web2, it's possible to authorize a third-party app (e.g., Zoom) to interact with a service (e.g., Google) on your behalf.

In Web3, however, there’s no common standard for authorization. As a result, each application (or ERC) has to implement its own method:

• For ERC20 tokens: approve(spender, amount).
• For ERC721 NFTs: setApprovalForAll(operator, approved).

More importantly, handling authorization at the contract level is deeply limiting. If you want to authorize a third party to mint NFTs for you, the contract-level function setApprovalForAll (which only concerns transfers) is insufficient.

What we need is a Web3 equivalent of JWTs—a universal standard for authorizing third parties to perform actions on your behalf. Since expecting all contracts to conform is difficult, the solution is to implement authorization at the wallet level.

Use the Wallet, Duh

The most obvious way to authorize someone to do something for you is to give them your seed phrase, which gives them the ability to interact with any contract. But this is overkill and unsafe.

So what if there was a way to give someone access to your wallet, but in such a way that they could only send a limited set of transactions for you?

Session Keys are the JWTs of Web3

Enter session keys—a feature of ZeroDev AA wallets wherein you can create temporary keys that are scoped to only certain transactions, with an expiration time.

Session keys are the JWTs of Web3. Much like JWTs, session keys are:

• Cryptographically Signed: Signed with your master key.
• Scoped: They encode specific "scopes" that specify the actions they can perform.
• Time-Limited: They can be created with an expiration time to limit the consequences of keys being leaked.

While similar, session keys are fundamentally more powerful because they are programmable, allowing for far more granular and custom permissions than a fixed JWT standard.

JWTs vs. Session Keys Comparison (Webflow Friendly)

Granular Permissions

• JWTs (Web2): Provide permissions for specific actions on the platform.
• Session Keys (Web3): Provide permissions for specific actions across different contracts, while setting parameters for actions, like a maximum gas amount, maximum transaction volume, etc.

Expiration Time

• JWTs (Web2): Have an expiration time, requiring token refresh or user re-authentication.
• Session Keys (Web3): Also have an expiration time, ensuring temporary permissions.

User Experience

• JWTs (Web2): Allows users to stay logged in across sessions and share sessions across devices.
• Session Keys (Web3): Enables users to interact with a DApp within pre-set rules without signing every transaction.

Security

• JWTs (Web2): If compromised, the impact depends on the scope of the permissions granted.
• Session Keys (Web3): If compromised, the potential damage is limited by the key's specific rules and parameters (e.g., max tokens, max gas).

Decentralization

• JWTs (Web2): Issued and verified by a centralized server.
• Session Keys (Web3): Issued and verified by the user's wallet, and are entirely decentralized.

Interoperability

• JWTs (Web2): Limited to platforms that support JWTs.
• Session Keys (Web3): Universally compatible with DApps on any blockchain that supports AA wallets.

Trust

• JWTs (Web2): Trust in the central server is required for issuance and verification.
• Session Keys (Web3): Trust is not required as rules are set by the user and signed with the user’s master key.

Empowering DApps with Session Keys

It’s hard to overstate the impact of a flexible and interoperable means of authorization. By taking advantage of session keys, DApps can create experiences that are simply impossible to create otherwise.

Session keys allow transactions that seem "automatic" from the user's perspective, in two forms:

• Skipping confirmations while the user is online: Most useful in social and gaming applications, where frequent, small transactions disrupt the experience. The user pre-authorizes a range of transactions, allowing them to enjoy the game uninterrupted.
• Executing transactions when the user is offline: Allows users to authorize an offline bot to purchase an NFT at drop time, or enables DeFi applications to automatically exit risky positions to prevent liquidation.

Use Session Keys with ZeroDev Today

ZeroDev offers what it believes to be the most advanced implementation of session keys:

• Off-chain Creation: Generating a new session key does NOT require an on-chain transaction or gas.
• Fine-Grained Scoping: Keys can define the scope of transactions based on various parameters such as contract addresses, function names, and ERC-165 interfaces (e.g., ERC20/ERC721).
• Public Key Authorization: A client can create a public-private key pair and send just the public key to the master signer for authorization, ensuring the private part of the session key never needs to be shared.

Session keys are available with ZeroDev today. Get started here and build some groundbreaking DApps!

The Road Ahead

The quest to fix Web3 UX is a long one, but session keys are a significant step towards this goal, offering a practical and secure solution to a major issue—the lack of authorizations—that has been largely overlooked until now.

As more projects adopt session keys and AA in general, we will see the gap between Web2 and Web3 experiences begin to close. ZeroDev is proud to be a part of this journey!