Skip to main content

BYOA: Bring Your Own Authentication

BYOA is Diosc's security model where the AI borrows the user's authentication instead of having its own credentials. This is the foundation of how Diosc integrates securely with enterprise systems.

The Core Principle​

The AI is not a separate user - it's an extension of the logged-in user.

When a user interacts with Diosc, their authentication token (JWT, session cookie, API key, etc.) is forwarded through the entire chain:

The same auth token flows through the entire chain.

Your API validates the token and enforces permissions exactly as it would for a direct user request. Diosc Hub never validates or stores credentials - it simply passes them through.

Why BYOA?​

The Problem with AI Service Accounts​

Traditional AI integrations use service accounts:

AI Bot logs in with: ai-bot@company.com / secret-password
AI Bot has: Admin access to all systems

Problems:

  • AI can access anything (security risk)
  • Audit logs show "AI Bot" (who actually requested this?)
  • Credential rotation is complex
  • Permission management is a nightmare
  • Multi-tenancy requires custom logic

The BYOA Solution​

User logged in with: john@company.com
AI uses: John's existing token
AI can access: Only what John can access

Benefits:

  • AI has exactly the user's permissions (no more, no less)
  • Audit trails show the real user
  • No credentials to manage for AI
  • Multi-tenancy is automatic (user's tenant ID is in their token)
  • Works with any auth system

How It Works​

Step 1: Capture User's Auth (Frontend)​

Your application provides the user's authentication to Diosc components:

// Configure auth provider
diosc('auth', async () => ({
  headers: {
    'Authorization': `Bearer ${getAccessToken()}`
  },
  userId: getCurrentUserId()
}));

Step 2: Forward to Hub (WebSocket)​

When the user sends a message, their auth context travels with it:

// This happens automatically
{
  message: "Show me my orders",
  userAuth: {
    headers: { "Authorization": "Bearer eyJhbG..." },
    userId: "user_123"
  }
}

Step 3: Pass to MCP Servers​

Diosc Hub forwards the auth to your MCP servers:

// MCP request includes user's auth
fetch(mcpServer.url, {
  headers: {
    ...userAuth.headers,  // User's original auth
    'X-User-ID': userAuth.userId
  }
});

Step 4: Your API Validates​

Your existing API validates the token as usual:

// Your normal auth middleware
if (!validateToken(request.headers.authorization)) {
  throw new UnauthorizedException();
}

// Your normal permission check
if (!user.canAccessOrder(orderId)) {
  throw new ForbiddenException();
}

Token Refresh​

User tokens expire. Diosc handles this transparently:

diosc('auth', async () => {
  // Check if token is about to expire
  if (isTokenExpiring()) {
    await refreshToken();
  }

  return {
    headers: { 'Authorization': `Bearer ${getAccessToken()}` }
  };
});

The auth provider is called before each request, so you can refresh as needed.

Manual Refresh​

If the token expires mid-conversation, Diosc emits an event:

diosc('on', 'auth_expired', async () => {
  // Show login modal or redirect
  await promptUserToReauthenticate();

  // Reconnect with new token
  diosc('reconnect');
});

Security FAQ​

Q: If Diosc Hub doesn't validate tokens, isn't that insecure?​

No. Security is enforced at the right layer - your API. Diosc Hub is just a messenger, like a proxy that forwards requests. Your API:

  • Validates the token
  • Checks permissions
  • Enforces rate limits
  • Logs access

The security model is unchanged from direct API access.

Q: Can a malicious user forge tokens?​

They could try, but:

  1. They can already attempt this with direct API calls
  2. Your API validation catches invalid tokens
  3. Diosc doesn't make forgery easier or harder

Q: What data does Diosc Hub store?​

  • Stored: Conversation history, user ID (for queries), tenant ID (for isolation)
  • Not stored: Authentication tokens, passwords, session cookies

Auth headers exist only in memory during request processing.

Q: Can the AI access data the user can't?​

No. The AI uses the user's token, so your API enforces the user's permissions. If John can't see Alice's orders, the AI can't see them either when John is using it.

Multi-Tenancy​

BYOA makes multi-tenancy automatic:

No additional configuration needed - tenant isolation comes from your existing auth system.

Implementation Checklist​

When integrating with BYOA:

  • Auth provider configured - diosc('auth', ...) returns current user's headers
  • Token refresh handled - Either automatic refresh or auth_expired event handler
  • MCP servers forward auth - Pass through Authorization header to your APIs
  • APIs validate normally - No changes to your existing auth middleware
  • User ID extracted - For conversation queries and audit logs

Next Steps​