Skip to Content
Architecture BlueprintToken Cryptography & Verification

Cryptography, Bitmasks & Local Validation

To achieve sub-millisecond, zero-lookup authentication, NexID Auth-DPoP relies on ultra-fast asymmetric cryptography and high-performance bitwise math. This enables application servers to perform validation locally in CPU memory.

1. Token Cryptography: EdDSA (Ed25519) vs. RSA

NexID Auth utilizes EdDSA (specifically Ed25519) as its primary signing algorithm.

  • CPU Execution Limits: Cloudflare Workers are billed and throttled based on CPU execution time. An Ed25519 sign operation is up to 10x faster than an RSA-2048 sign operation, significantly reducing Worker execution time and billable usage.
  • Payload Footprint: An RSA-2048 signature requires a 256-byte signature, ballooning the HTTP header payload. An Ed25519 key requires only a 32-byte public key and a 64-byte signature, yielding compact JWTs ideal for high-frequency edge transit.
  • Deterministic Signatures: Unlike traditional ECDSA, EdDSA does not require a high-entropy random number generator at the time of signing. It is deterministic, preventing private key leakage through flawed random entropy pools at the edge.

2. Permission Bitmask System

Instead of passing an array of string permissions (e.g., ["posts:read", "posts:write"]) which increases token size and processing time, NexID Auth uses bitwise operations.

Bitmask Mapping Configuration

Permissions are mapped to powers of 2 (individual bits in an integer):

enum Permissions {
  NONE         = 0,        // 00000000
  READ_POSTS   = 1 << 0,   // 00000001 (Decimal: 1)
  WRITE_POSTS  = 1 << 1,   // 00000010 (Decimal: 2)
  DELETE_POSTS = 1 << 2,   // 00000100 (Decimal: 4)
  MANAGE_USERS = 1 << 3,   // 00001000 (Decimal: 8)
  BILLING      = 1 << 4,   // 00010000 (Decimal: 16)
}

Merging Permissions

If a user is assigned READ_POSTS and WRITE_POSTS, their bitmask is computed using the bitwise OR (|) operator:

Bitmask = READ_POSTS | WRITE_POSTS = 1 | 2 = 3 (Binary: 00000011)

Verifying Permissions (At App Server)

To check if a request to delete a post is authorized, the application server extracts the permissions claim from the verified JWT and applies the bitwise AND (&) operator against the required permission:

const required = Permissions.DELETE_POSTS; // 4 (00000100)
const userPerms = jwt.payload.permissions;  // 3 (00000011)
 
const isAuthorized = (userPerms & required) === required;
// (00000011 & 00000100) => 00000000 (Decimal: 0)
// 0 !== 4 -> Access Denied!

This evaluation runs in microseconds, requires no memory overhead, and keeps token sizes exceptionally small.

3. Resource Server Local Validation Protocol

When a downstream application server receives an API request, it validates the credentials locally on CPU memory using the following checklist.

Verification Checklist

  1. Authorization Headers: Ensure both the Authorization header (carrying the DPoP-bound access token) and the DPoP header (carrying the DPoP proof JWT) are present.
  2. Access Token Signature: Retrieve the public key matching the token’s kid from the cached JWKS (retrieved from /.well-known/jwks.json) and verify the access token’s signature.
  3. DPoP Proof Signature: Extract the client’s public jwk from the DPoP proof header and verify the proof signature.
  4. Key Thumbprint Binding: Compute the SHA-256 thumbprint of the client’s public key from the DPoP proof header. Verify it matches the cnf.jkt claim inside the access token.
  5. DPoP Proof Claims: Validate that:
    • The htm claim matches the request’s HTTP method.
    • The htu claim matches the request’s destination URL path.
    • The iat timestamp is within the allowable window (e.g. within 60–120 seconds).
  6. JTI Cache Lookup: Query Upstash Redis (or a local cache) to verify that the proof’s jti unique ID has not been used before.
  7. Local Bitmask Evaluation: Perform the bitwise & check to ensure the user has all necessary permissions.
Database BlueprintAPI Reference