Skip to content

Authentication and Authorization in KDB.AI

This page explains how authentication works in KDB.AI and introduces the two supported mechanisms: static authentication and OAuth 2.0.

If you're already familiar with this topic, you can skip ahead to the Set Up Static Authentication and OAuth 2.0 Authentication and Authorization how-to guides.

Authentication is the first layer of security in a KDB.AI deployment. It determines who is allowed to connect to the system and ensures that only trusted clients can issue queries, ingest data, or administer the platform.

When you enable authentication, every incoming request must include valid credentials. KDB.AI verifies those credentials before allowing the request to proceed. It also supports authorization through internal ACL management.

Different deployments have different security requirements. KDB.AI therefore offers two authentication models, each suited to specific environments:

The sections below provide an overview of both mechanisms and the scenarios in which each is appropriate.

Static authentication

Architecture

Static authentication uses a single shared password configured on the server. When a client connects, KDB.AI compares the provided password with the configured secret. If the password matches, the request proceeds. KDB.AI does not integrate with an identity provider in this mode and does not evaluate tenants, groups, or ACL grants.

flowchart LR

    Client[Client]
    KDBAI[KDB.AI]
    Secret[Configured Secret = env variable or mounted file]

    Client --> KDBAI
    Secret --> KDBAI

Benefits

Static authentication keeps the access model straightforward and centralized within the server configuration:

  • No external dependencies: does not require an identity provider or network access to external services.
  • Works for both connection types: supports TCP/QIPC and HTTP authentication when enabled.
  • Predictable behavior: all authenticated clients receive the same level of access.
  • Low operational overhead: you configure one secret on the server. There are no JWT claims, issuers, or ACL grants to maintain.

When to use

Static authentication keeps configuration minimal and centralizes access control in the server itself. We recommend it when:

  • You need a single shared password to control access.
  • All authenticated clients should have the same access level.
  • You do not require tenant separation.
  • You do not require group-based permissions.
  • You do not use an external identity provider.

For setup details, go to the Set Up Static Authentication in KDB.AI how-to guide.

OAuth 2.0 authentication and authorization

Architecture

OAuth 2.0 enables KDB.AI to authenticate users through an external identity provider while enforcing fine-grained authorization through internal ACL grants.

KDB.AI validates the token’s signature and issuer, then extracts the configured tenant and group claims (with claim field names defined by the user) to evaluate ACL grants.

flowchart LR

    IdP[Identity Provider]
    JWKS[JWKS Endpoint]
    Client[Client]
    KDBAI[KDB.AI]
    ACL[ACL Grants]

    IdP --> Client
    Client --> KDBAI
    IdP --> JWKS
    KDBAI --> JWKS
    KDBAI --> ACL

Benefits

OAuth 2.0 separates authentication (handled by the IdP) from authorization (handled by ACL grants in KDB.AI), allowing structured access control:

  • Group-based access control: uses group membership from the JWT to determine permissions.
  • Fine-grained authorization: uses ACL grants to control access at the database or table level.
  • Defined system administrator role: supports a system administrator role based on configured tenant and group values.

When to use

OAuth 2.0 allows KDB.AI to rely on the identity provider for user and group management while enforcing authorization through ACL grants. We recommend it when:

  • You need to separate access by namespace such as tenant, org, or team.
  • You need to control permissions by group.
  • You want to grant different levels of access to different teams.
  • You need database-level or table-level access control.
  • You require a defined system administrator role.
  • You already use an identity provider (for example, Keycloak, Entra ID, or Okta).

For configuration and examples, go to the OAuth 2.0 Authentication and Authorization how-to guide.

Comparison

Each authentication method offers different levels of control and operational complexity. The table below summarizes the main differences so you can select the approach that best fits your deployment.

Feature Static authentication OAuth 2.0 authentication and authorization
External identity provider No Yes
Credential type Shared password JWT access token
Identity source Configured on server Managed by identity provider
Tenant support No Yes
Group-based access control No Yes
Fine-grained permissions No Yes (through ACL grants)
Authorization model Same access for all authenticated clients Access based on tenant and group claims
System administrator role No Yes
Operational complexity Low Higher (IdP and ACL configuration)

Summary

Static authentication provides a single shared access boundary: all authenticated clients operate with the same permissions.

OAuth 2.0 authentication separates identity management – handled by the identity provider – from authorization, which is defined through ACL grants in KDB.AI. Access depends on the tenant and group claims present in the token.

Use static authentication when you only need simple access restriction. Choose OAuth 2.0 authentication and authorization when you require structured access control, group‑based permissions, or tenant separation.

Next steps