Overview

OASIS supports two authentication modes side-by-side:

Both modes issue the same JWT token on success, so the rest of the API is identical regardless of which auth path was used.

Standard JWT Flow

  1. Client calls POST /api/avatar/authenticate with credentials.
  2. ONODE validates, returns jwtToken (7-day expiry).
  3. Client includes Authorization: Bearer <token> on all subsequent requests.
  4. On expiry, client re-authenticates. There is no refresh token — re-login is required.
⚠️
Store the token securely

In browser OApps, store the JWT in localStorage (acceptable for non-sensitive OApps) or in an HttpOnly cookie (preferred for high-security applications). Never expose it in URLs or logs.

DID Auth Flow

DID auth uses a nonce-based challenge/response pattern:

  1. Client presents its DID to the ONODE.
  2. ONODE looks up the DID document to find the verification method (public key).
  3. ONODE generates a one-time nonce and returns it to the client.
  4. Client signs the nonce with its private key and returns the signature.
  5. ONODE verifies the signature against the DID document public key.
  6. On success, ONODE issues a JWT for the associated avatar.

Nonce Store

DID auth nonces must be stored server-side to prevent replay attacks. OASIS supports two nonce store backends, configured in OASISDNA.json:

StoreConfig valueNotes
In-memoryMemoryDefault. Works on a single ONODE. Not suitable for multi-node deployments.
RedisRedisRequired for ONET multi-node clusters. Set RedisConnectionString alongside.
ℹ️
ONET nodes require Redis

When an ONODE joins ONET with DID auth enabled, it must use the Redis nonce store. Using in-memory will cause nonce validation failures across node boundaries and generate a startup warning in the ONODE logs.

Enabling DID Auth

json — OASISDNA.json
{
  "OASISDNA": {
    "EnableDIDAuth": true,
    "NonceStoreType": "Redis",
    "RedisConnectionString": "localhost:6379"
  }
}