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 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: Provide the User's Auth​

Your application provides the user's authentication to Diosc:

diosc('auth', {
  headers: {
    'Authorization': `Bearer ${accessToken}`
  },
  userId: currentUser.id,
  tenantId: currentUser.tenantId
});

Step 2: Auth Flows with Every Request​

When the user sends a message, their auth context travels with it automatically. You don't need to manage this — Diosc handles the forwarding.

Step 3: Your MCP Servers Receive the Auth​

Your MCP servers receive the user's original auth headers and can use them when calling your APIs:

// In your MCP server tool handler
async function listOrders(params, context) {
  // context.headers contains the user's original auth
  const response = await fetch('https://api.example.com/orders', {
    headers: context.headers  // User's token forwarded as-is
  });
  return response.json();
}

Step 4: Your API Validates as Usual​

Your existing API validates the token and enforces permissions — no changes needed:

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

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

Token Refresh​

User tokens expire. When the current token is about to expire or has expired, push a fresh auth context:

// Push updated auth with a new token (same userId = token refresh)
diosc('auth', {
  headers: { 'Authorization': `Bearer ${newAccessToken}` },
  userId: currentUser.id  // Same user — Diosc treats this as a refresh
});

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

diosc('on', 'auth:refresh_required', ({ reason }) => {
  // Get a fresh token from your auth system
  const newToken = await refreshAccessToken();

  // Push updated auth
  diosc('auth', {
    headers: { 'Authorization': `Bearer ${newToken}` },
    userId: currentUser.id
  });
});

Security FAQ​

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

No. Security is enforced at the right layer — your API. Diosc is just a messenger 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 store?​

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

See Credential-Blind Architecture for details.

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. You provide the tenantId when pushing auth, and Diosc uses it for data isolation:

diosc('auth', {
  headers: { 'Authorization': `Bearer ${token}` },
  userId: 'john',
  tenantId: 'acme-corp'  // All session data scoped to this tenant
});

Your MCP servers receive the user's auth headers and your APIs enforce tenant isolation as usual — no additional configuration needed.

Implementation Checklist​

When integrating with BYOA:

  • Push auth context — diosc('auth', { headers, userId, tenantId }) with the current user's token
  • Handle token refresh — Push updated auth context when tokens expire, or listen for auth:refresh_required
  • MCP servers forward auth — Pass through the Authorization header when calling your APIs
  • APIs validate normally — No changes to your existing auth middleware
  • Handle logout — Call diosc('auth', null) when the user logs out

Next Steps​