This document describes the authentication and authorization mechanisms implemented in the EigenLayer-AVS system.
This document describes the authentication and authorization mechanisms implemented in the EigenLayer-AVS system. The authentication system secures communication between clients, operators, and the aggregator service using JWT (JSON Web Tokens) and Ethereum signature verification.
The EigenLayer-AVS implements two primary authentication methods:
These mechanisms ensure that only authorized entities can access protected endpoints and perform operations within the system.
Sources:
The user authentication flow follows these steps:
Initial Authentication: User sends a request to GetKey with either:
Signature Verification: If using signature-based authentication:
Token Issuance: Upon successful verification, a JWT token is issued to the user
Subsequent Requests: For all API requests, the user includes the JWT token in the authkey metadata field
Sources:
The operator authentication flow is currently simplified:
authorization header in their requestsverifyOperator function validates this authorization against the operator's addressenforceAuth flag set to falseThis design allows for backward compatibility with operators running older versions (pre-1.3) where authentication isn't enforced. The system plans to enable enforcement once all operators have updated to version 1.3.0 or higher.
Sources:
The JWT tokens used for authentication contain the following standard claims:
| Claim | Description | Implementation |
|---|---|---|
sub (Subject) | The Ethereum address of the authenticated user | User's wallet address |
exp (Expiration Time) | Token expiration timestamp | Derived from ExpiredAt parameter |
iss (Issuer) | Entity that issued the JWT | Set to constant auth.Issuer |
Additional security is provided by validating:
HS256)Sources:
The system provides two main verification functions:
verifyAuth - Validates user JWT tokens:
User modelverifyOperator - Validates operator authorization:
enforceAuth = false flagSources:
The system defines specific error constants for different authentication failure scenarios:
| Error Constant | Description | HTTP Status Code |
|---|---|---|
AuthenticationError | General authentication failure | 401 Unauthenticated |
InvalidSignatureFormat | Malformed or invalid signature format | 400 InvalidArgument |
InvalidAuthenticationKey | Invalid JWT or signature | 401 Unauthenticated |
InvalidAPIKey | Provided API key is not valid | 401 Unauthenticated |
MalformedExpirationTime | Invalid expiration time format | 401 Unauthenticated |
These error constants provide consistent and informative responses when authentication fails.
Sources:
The authentication system is integrated with the Aggregator service through the RPC server. When the Aggregator starts, it initializes various components including the RPC server, which handles authentication for incoming requests.
Sources:
config.JwtSecret) for signing and verifying tokensenforceAuth = false) to support backward compatibilityFuture improvements may include:
Sources:
For more information about other components that interact with the authentication system:
Feature this wiki to auto refresh weekly