Authentication

The ARN Server offers authentication-related APIs that allow you to sign a JSON Web Token (JWT) for your project.

Configuration Options

In the auth section of the ARN Server configuration, you can customize the authentication settings for your project. The configuration options include:

  • projectAdminApiKey: An API key to be included with requests that require a project administration role.
  • jwt: The configuration for the project's JWT signing service.
    • signingKeys: An array of JWT key definitions, each defined by a symbolic name, a secretOrPrivateKey, and additional options specified in the Json Web Token (JWT) documentation.
  • cors: The Cross-Origin Resource Sharing (CORS) configuration for your project.
    • origin: A regex pattern specifying the allowed origins for your project. Note that any restrictions here will also apply to admin clients, potentially limiting further admin requests, including the ability to roll back restrictions.
  • paths: An Access Control List (ACL) that determines which users or roles are allowed to access specific services. Each item in the array includes:
    • path: The service path, followed by a * to apply the rule to sub-paths as well.
    • action: An array of allowed actions such as create, read, update, and/or delete.
    • allowedTo: An array of roles allowed to perform the specified actions. Roles include:
      • anybody: Any user, even if not connected.
      • projectUser: Wallet-connected users.
      • projectAdmin: Requests that include the [projectAdminApiKey](https://www.notion.so/ARN-Server-Authentication-Guide-b8552debb96e4343830bceec87d6f7a2?pvs=21) as an x-api-key header.
      • rootAdmin: Requests that include the [ARN_ADMIN_ROOT_API_KEY](https://www.notion.so/ARN-Server-User-Guide-cb389ba9c6ef4c39bf2dd998ac007ac5?pvs=21) as an x-api-key header. The rootAdmin role has unrestricted access to any action on any path and does not need to be listed explicitly.

Default Configuration

The default auth configuration is as follows:

{
  "jwt": {
    "signingKeys": []
  },
  "projectAdminApiKey": "4rnPr0j3ct4dm1n",
  "cors": {
    "origin": "\\.*"
  },
  "paths": [
    {
      "path": "/",
      "action": ["update", "delete"],
      "allowedTo": ["projectAdmin"]
    },
    {
      "path": "/",
      "action": ["read"],
      "allowedTo": ["anybody"]
    },
    {
      "path": "/auth/jwt-sign",
      "action": ["create"],
      "allowedTo": ["projectUser"]
    },
    {
      "path": "/condition/execute",
      "action": ["create"],
      "allowedTo": ["projectUser"]
    },
    {
      "path": "/data/*",
      "action": ["read", "update", "create", "delete"],
      "allowedTo": ["projectAdmin"]
    },
    {
      "path": "/i18n/*",
      "action": ["read"],
      "allowedTo": ["anybody"]
    },
    {
      "path": "/i18n/*",
      "action": ["update", "create", "delete"],

 

Rest API

JWT Sign API

POST /:projectKey/auth/jwt-sign: returns a JWT signed with some project key. This route expects a project user authorization and a JSON payload with a keyName (referring to the key definition in the project configuration) and a jwt object (containing JWT properties such as sub, iat, etc.).

Server REST Format

Most ARN server remote API require the caller to authenticate as as wallet owner, so that the server can answer about some wallet-dependent conditions, typically.

Request

Below is the low level format of a such a request:

**POST** https://some-arn-server/some-project-key/some-api-path
**Authorization**: EthereumSig <signature>
**Content-Type:** application/json; charset=utf-8
**Content-Length:** xx

<JSON Payload>

<signature> is the result of the user signing through Wallet Connect typically. For instance:

**POST** https://my-arn-server/my-project/nft/list/
**Authorization**: EthereumSig eyJtZXNzYWdlIjoiQnkgc2lnbmluZyB0aGlzIG1lc3NhZ2UsIHlvdSBnaXZlIHVzZSBhY2Nlc3MgdG8gdGhlIGxpc3Qgb2YgTk...BpbiB5b3VyIFdhbGxldC4gV2UgY2FuJ3QgaGF2ZSB0aGUgcmlnaHQgdG8gbW9kaWZ5IHlvdXIgV2FsbGV0Iiwic2lnbmF0dXJlIjoiMHhjNTk4MjgxZTc3YWFhN2E1ZDAyMGM5NzY4MjRiOGU5ZGI1OGFlNzM3MTEyYTMwNzNmMmU4MWM2NGMxNzNkYTE2NTJiYTJjNGU1ZWVkZDc5YzUyMGZjZTEzZjhkMDBmNTRiYWE3MDFlNzNlZmQwYzZiOGFhNThhZTNjMTg4NDgwMzFiIn0=
**Content-Type:** application/json; charset=utf-8
**Content-Length:** 66

{
  "and": [{
    "opts": {
      "name": "hasTag",
      "tags": ["tag1", "tag2"]
    },
    "templateName": "HasArianeeSmartAsset"}
  ]
}

or:

**POST** https://my-arn-server/my-project/condition/execute/someCondition
**Authorization**: EthereumSig eyJtZXNzYWdlIjoiQnkgc2lnbmluZyB0aGlzIG1lc3NhZ2UsIHlvdSBnaXZlIHVzZSBhY2Nlc3MgdG8gdGhlIGxpc3Qgb2YgTk...BpbiB5b3VyIFdhbGxldC4gV2UgY2FuJ3QgaGF2ZSB0aGUgcmlnaHQgdG8gbW9kaWZ5IHlvdXIgV2FsbGV0Iiwic2lnbmF0dXJlIjoiMHhjNTk4MjgxZTc3YWFhN2E1ZDAyMGM5NzY4MjRiOGU5ZGI1OGFlNzM3MTEyYTMwNzNmMmU4MWM2NGMxNzNkYTE2NTJiYTJjNGU1ZWVkZDc5YzUyMGZjZTEzZjhkMDBmNTRiYWE3MDFlNzNlZmQwYzZiOGFhNThhZTNjMTg4NDgwMzFiIn0=
**Content-Type:** application/json; charset=utf-8
**Content-Length:** 66

{
  "filter": {
    "tags": ["myTag"]
  }
}

Signature

Once the signing step has succeeded, the authorization header [can be re-generated at any time using the proper client API.

The ARN server will return:

**Content-Type:** application/json; charset=utf-8

<JSON payload>

For instance, as the result of a condition check:

Content-Type: application/json; charset=utf-8

{
  "executions": [
    { "name": "hasTag", "success": false }
  ],
  "success":false
}