ERC-4337 authentication

ERC-4337 authentication methods

ERC-4337 supports various authentication methods, allowing users to choose the most suitable option for their needs. Here are some of the authentication methods currently available:

1. Traditional methods in blockchain
- private key signatures
- EIP-1193 signers.

2. Passkeys & WebAuthn
- Integration with platform-specific secure authentication.
- Example: Apple IOS passkeys
- WebAuthn is a popular authentication framework leveraging authenticators build directly in the device.

3. Session Keys:

Before delving ito the matter, let’ s make a quick refesher about session keys in the global web landscape as they have their importance in this account abstraction architecture. Session keys are unique identifier that a web server assigns to a user’s browser during a specific session to authenticate and maintain a secure connection with the service for a limited time period. This session typically starts when a user visits a website and the session ends when the user closes the browser or log out.

1) Initialization: When a user first visits a website, the server generates a random session keys and sends it to the user’s browser.
2) Storage: The browser stores the session key in a cookie or local storage.
3) Verification: With each subsequent request, the browser sends the session keys back to the server. The server verifies the key to ensure that the user is still authenticated.

In the context of ERC-4337 account abstraction , session keys serve a similar purpose but with blockchain-specific implications:

1) They allow users to delegate limiteless permissions(if they choose to do so) to Decentralized Apps without exposing their private keys.
2) Session keys can be created with specific scopes , time limits or transaction limits, enhancing security & control.
3) Session keys enable smoother user experiences by reducing the need for frequent wallet interactions and signatures.
4) Supports authentication via third-party providers: - Google Account/email login. - Facebook, etc…
5) Custom code directly in the AA-enabled smart contract or using specialized sdks (Alchemy signer, ZeroDev , Biconomy SDKs, …).

Below is an example of a custom authentication in your AA contract, we simply override the ‘_validateSignature’ method from eth-infinitism:
 

// Imports  from OpenZeppelin & from github.com/eth-infinitism
import {IAccount} from "lib/account-abstraction/contracts/core/IAccount.sol";
import { SIG_VALIDATION_SUCCESS, SIG_VALIDATION_FAILED} from "lib/account-abstraction/contracts/core/helpers.sol";
import { MessageHashUtils} from "@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol";
import {ECDSA } from "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";



/// @notice Helper function to validate the signature of the user operation.
/// @dev This function recovers the signer of the user operation and validate that it is the owner of the contract.
/// @param userOp The userOperation to validate 
/// @param userOpHash The hash of the userOperation 
/// @return validationData SIG_VALIDATION_SUCCESS if signature is valid , SIG_VALIDATION_FAILEED otherwise
contract CustomAAcontract is IAccount {
    address public owner;

    function _validateSignature(PackedUserOperation calldata userOp,bytes32 userOpHash) 
    internal view returns (uint256 validationData) {
        bytes32 hash = MessageHashUtils.toEthSignedMessageHash(userOpHash);
        if (owner != ECDSA.recover(hash, userOp.signature))
            return SIG_VALIDATION_FAILED;
        return SIG_VALIDATION_SUCCESS;
    }

    // Other contract functions...
}

  In this implementation, we use ‘MessageHashUtils.toEthSignedMessageHash()’ to ensure comptatibilty with EIP-191 standard, making it wotk with most Ethereum wallets. The signature is validated using OpenZeppelin’ s ‘ECDSA.recover()’ function.