While session keys unlock new ways to create engaging consumer experiences, improper or malicious implementations of session keys create new ways for bad actors to steal assets from users. Session keys are permissionless on testnet, however, mainnet enforces several security measures to protect users. This document outlines the security restrictions and best practices for using session keys.

​
Session Key Policy Registry

Session keys are restricted to a whitelist of allowed policies on Abstract Mainnet through the Session Key Policy Registry contract, which manages a whitelist of approved session keys. Applications must pass a security review before being added to the registry to enable the use of session keys for their policies.

​
Restricted Session Key Policies

Session key policies that request approve and/or setApprovalForAll functions must be passed with additional constraints that restrict the approval to a specific contract address. For example, the following policy must include a constraints array that restricts the approval to a specific contract address, or will be rejected with “Unconstrained token approval/transfer destination in call policy.” 
{
  target: "0x...",
  selector: toFunctionSelector("approve(address, uint256)"),

  // Must include a constraints array that restricts the approval to a specific contract address
  constraints: [
    {
      condition: ConstraintCondition.Equal,
      index: 0n,
      limit: LimitType.Unlimited,
      refValue: encodeAbiParameters(
        [{ type: "address" }],
        ["0x-your-contract-address"]
      ),
    },
  ],
}

​
Session Key Signer Accounts

Session keys specify a signer account; an that is permitted to perform the actions specified in the session configuration. Therefore, the private key of the signer(s) you create are SENSITIVE VALUES! Exposing the signer private key enables attackers to execute any of the actions specified in a session configuration for any AGW that has approved a session key with that signer’s address. 
await agwClient.createSession({
  session: {
    signer: sessionSigner.address, // <--- The session key signer account
    // ...
  },
});
Below is an example implementation of creating a unique signer account for each session key, and storing them encrypted in the browser’s local storage.

Example Repo: Encrypted Unique Signer Keys in Local Storage

View the example repository for generating unique signer accounts and storing them encrypted in the browser’s local storage.

​
Risks of Using Session Keys

Temporary keys enable transactions without owner signatures; this functionality introduces several legal risks that developers should be aware of, particularly around security and data management. These include:
  • If session keys are compromised, they can be used for unauthorized transactions, potentially leading to financial losses.
  • Failing to follow recommended practices, such as creating new keys per user or managing expiration, could result in security vulnerabilities.
  • Storing session keys, even when encrypted, risks data breaches. You should comply with applicable data protection laws.