Authentication and authorization
Authentication and authorization are closely related concepts, and sometimes abbreviated as AuthN and AuthZ. Authentication (AuthN) is the process of verifying the identity of a user, while authorization (AuthZ) is the process of determining what permissions the user has.
Authentication
Weaviate controls access through user authentication via API keys or OpenID Connect (OIDC), with an option for anonymous access. Users can then be assigned different authorization levels, as shown in the diagram below.
For example, a user logging in with the API key jane-secret may be granted administrator permissions, while another user logging in with the API key ian-secret may be granted read-only permissions.
API key and OIDC authentication can be both enabled at the same time. We recommend using a client library to authenticate against Weaviate. See How-to: Connect pages for more information.
For Weaviate Cloud (WCD) instances, authentication is pre-configured with API key access. You can authenticate against Weaviate by creating new API keys.
API key
API key authentication is the simplest method to authenticate against Weaviate. Each user is assigned a unique API key, which is passed in the request header. For details on configuring API key authentication, see the authentication guide.
OpenID Connect (OIDC)
OpenID Connect (OIDC) enables authentication through an external identity provider (e.g., Okta, Azure AD, Google). OIDC supports multiple flows such as client credentials, resource owner password, and hybrid flow. For details on configuring OIDC and working with tokens, see the OIDC configuration guide.
Anonymous access
Anonymous access allows unauthenticated requests. This is strongly discouraged except for local development or evaluation purposes, as it bypasses all identity verification.
Authorization
Weaviate provides differentiated access through authorization levels, based on the user's authentication status.
The following authorization schemes are available:
RBAC (recommended)
Role-Based Access Control (RBAC) provides fine-grained control over user permissions. With RBAC, you define roles with specific permissions and assign them to users. This is the recommended authorization scheme for production deployments.
RBAC supports:
- Predefined roles:
root(full access) andviewer(read-only access) - Custom roles: Create roles with specific permissions for collections, objects, tenants, backups, and more
- Granular permissions: Control access at the collection, tenant, and operation level using name filters and regex patterns
See RBAC Overview for the full permissions model, and Configuring RBAC for setup instructions.
Admin list (legacy)
The Admin list authorization scheme only provides coarse-grained access control (admin or read-only). Use RBAC instead for production deployments, as it provides much more flexible and secure permission management.
The Admin list scheme assigns users as either admin (full access) or read-only. Anonymous users can optionally be granted permissions.
Undifferentiated access
With undifferentiated access, all authenticated users have full access. This is only suitable for development or trusted single-user environments.
Further resources
- Configuration: Authentication
- Configuration: Authorization
- Configuration: OIDC
- Configuration: RBAC
- Configuration: Environment variables - Authentication and Authorization
Questions and feedback
If you have any questions or feedback, let us know in the user forum.