# Feast Authentication and Authorization Options: OIDC, Kubernetes RBAC, and No-Auth Configuration

> Explore Feast authentication options including OIDC, Kubernetes RBAC, and no-auth. Integrate with authorization managers for granular API permissions.

- Repository: [Feast/feast](https://github.com/feast-dev/feast)
- Tags: deep-dive
- Published: 2026-03-01

---

**Feast supports three built-in authentication modes—no authentication (`no_auth`), OpenID Connect (OIDC), and Kubernetes RBAC—that integrate with a pluggable authorization manager to enforce role, group, or namespace-based permissions at the API level.**

The feast-dev/feast repository implements a flexible authentication framework configured through [`feature_store.yaml`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml). This system extracts user identity from incoming requests and evaluates it against registry-stored permissions before allowing access to feature data.

## Built-in Authentication Modes

Feast provides three distinct authentication strategies, each defined in [`sdk/python/feast/permissions/auth_model.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/permissions/auth_model.py) and validated through `ALLOWED_AUTH_TYPES` in [`sdk/python/feast/repo_config.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/repo_config.py).

### No Authentication (`no_auth`)

**`no_auth`** disables all token handling and permission checks, accepting every request without validation.

- **Configuration**: Set `auth: {type: no_auth}` in [`feature_store.yaml`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml)
- **Implementation**: `NoAuthConfig` class in [`sdk/python/feast/permissions/auth_model.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/permissions/auth_model.py)
- **Use case**: Local development, CI/CD pipelines, and single-node testing environments

### OpenID Connect (OIDC) Authorization

**OIDC authentication** enables JWT-based security using external identity providers such as Keycloak, Auth0, or Azure AD. Clients obtain access tokens from the provider and transmit them as bearer tokens on each request.

- **Server-side configuration**: `auth: {type: oidc, auth_discovery_url: "...", client_id: "..."}`
- **Client-side configuration**: Supports three credential flows via `OidcClientAuthConfig`:
  1. **Static token**: Directly provide a `token` field
  2. **Client-credentials flow**: Provide `client_secret` (machine-to-machine)
  3. **Resource Owner Password Grant (ROPG)**: Provide `username`, `password`, and `client_secret`
- **Token processing**: `OidcTokenParser` in [`sdk/python/feast/permissions/auth/oidc_token_parser.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/permissions/auth/oidc_token_parser.py) validates JWT signatures, expiration, and extracts roles from the `resource_access` claim
- **Client management**: `OidcAuthClientManager` handles token exchange and refresh

### Kubernetes RBAC Authorization

**Kubernetes authentication** leverages service-account tokens automatically mounted in pods. Feast calls the Kubernetes TokenAccessReview API to discover the service-account's groups, namespaces, and bound roles.

- **Configuration**: `auth: {type: kubernetes, user_token: <optional>}` (omit `user_token` to use the pod's default service-account token)
- **Implementation**: `KubernetesAuthConfig` class in [`sdk/python/feast/permissions/auth_model.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/permissions/auth_model.py)
- **Use case**: Production deployments inside Kubernetes clusters where you want to reuse existing RBAC policies for intra-cluster services

## How the Authorization Pipeline Works

Feast authorizes requests through a multi-stage pipeline implemented in the permissions server utilities:

1. **Configuration parsing**: When a Feast server starts, `RepoConfig` reads the `auth` block from [`feature_store.yaml`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml) and instantiates the appropriate auth configuration class.

2. **Token extraction**: The `AuthManager` delegates to a **TokenExtractor** implementation (e.g., `OidcTokenExtractor` or `KubernetesTokenExtractor`) to retrieve the bearer token from the HTTP request headers.

3. **Token parsing**: 
   - For OIDC, `OidcTokenParser` verifies the JWT against the discovery URL and extracts role information.
   - For Kubernetes, the parser executes a TokenAccessReview to retrieve the service-account's group memberships and namespace bindings.

4. **Permission evaluation**: The extracted user attributes feed into the **Permission Engine** (`feast.permissions.server.utils`). This engine compares the requester's roles against `Permission` objects stored in the registry (documented in [`docs/reference/registry/registry-permissions.md`](https://github.com/feast-dev/feast/blob/main/docs/reference/registry/registry-permissions.md)).

5. **Enforcement**: Every API endpoint in the Feast server checks the current request's permission context before performing create, read, update, or delete operations on feature views, entities, or data sources.

## Configuration Examples

### Server-Side OIDC Configuration

```yaml
project: my-project
registry:
  path: data/registry.db
online_store:
  type: sqlite
auth:
  type: oidc
  auth_discovery_url: https://keycloak.example.com/realms/feast/.well-known/openid-configuration
  client_id: feast-server

```

The server creates an `OidcAuthManager` at startup and validates every incoming bearer token against the specified discovery endpoint.

### Server-Side Kubernetes RBAC Configuration

```yaml
project: my-project
registry:
  path: data/registry.db
online_store:
  type: sqlite
auth:
  type: kubernetes

```

If you omit `user_token`, Feast automatically extracts the token from `/var/run/secrets/kubernetes.io/serviceaccount/token` inside the pod.

### Client-Side OIDC (Client-Credentials Flow)

```yaml
project: my-project
registry:
  registry_type: remote
  path: feast-registry.example.com:80
online_store:
  type: remote
  path: http://feast-feature-server.example.com:80
auth:
  type: oidc
  auth_discovery_url: https://keycloak.example.com/realms/feast/.well-known/openid-configuration
  client_id: feast-client
  client_secret: <secret-value>

```

```python
from feast import FeatureStore

store = FeatureStore(repo_path=".")

# The client automatically exchanges client_secret for a token

features = store.get_online_features(
    feature_refs=["driver:rating"],
    entity_rows=[{"driver_id": 1001}]
).to_df()

```

### Client-Side Kubernetes (In-Cluster)

```yaml
project: my-project
registry:
  registry_type: remote
  path: feast-registry.default.svc:80
online_store:
  type: remote
  path: http://feast-feature-server.default.svc:80
auth:
  type: kubernetes

```

```python
from feast import FeatureStore

store = FeatureStore(repo_path=".")

# No explicit credentials; SDK reads the pod's service-account token

features = store.get_online_features(
    feature_refs=["driver:rating"],
    entity_rows=[{"driver_id": 1001}]
).to_df()

```

### Disabling Authentication

```yaml
project: quick-start
registry:
  path: data/registry.db
online_store:
  type: sqlite
auth:
  type: no_auth

```

## Summary

- Feast implements a **pluggable authorization manager** that supports `no_auth`, OIDC, and Kubernetes RBAC modes configured via [`feature_store.yaml`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml).
- **OIDC integration** in [`sdk/python/feast/permissions/auth/oidc_token_parser.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/permissions/auth/oidc_token_parser.py) validates external JWTs and extracts role claims for cross-cluster authentication.
- **Kubernetes RBAC** leverages in-cluster service-account tokens and the TokenAccessReview API to enforce namespace and group-based permissions.
- The **Permission Engine** evaluates every API request against registry-stored permissions after extracting and parsing the authentication token.
- For mixed environments, use OIDC for external clients and Kubernetes auth for intra-cluster services, configuring each component's `auth` block independently.

## Frequently Asked Questions

### What is the default authentication mode in Feast?

If you do not specify an `auth` block in [`feature_store.yaml`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml), Feast defaults to `no_auth`, which disables all permission checks and accepts every request. This is suitable for development but should be explicitly changed to `oidc` or `kubernetes` for production deployments.

### Can OIDC and Kubernetes authentication be used simultaneously?

Yes. You can configure different Feast components with different auth types depending on their deployment context. For example, configure the feature server with `type: oidc` to accept external client tokens, while clients running inside the Kubernetes cluster use `type: kubernetes` to authenticate with their service-account tokens. Each component reads its own [`feature_store.yaml`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml) configuration independently.

### How does Feast validate OIDC tokens?

Feast validates OIDC tokens in [`sdk/python/feast/permissions/auth/oidc_token_parser.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/permissions/auth/oidc_token_parser.py). The parser fetches the JSON Web Key Set (JWKS) from the `auth_discovery_url`, verifies the JWT signature and expiration, and extracts the `resource_access` claim to determine the user's roles. These roles are then matched against Feast `Permission` objects to authorize the requested operation.

### Where are permissions defined in Feast?

Permissions are stored in the Feast registry and evaluated by the Permission Engine at runtime. As documented in [`docs/reference/registry/registry-permissions.md`](https://github.com/feast-dev/feast/blob/main/docs/reference/registry/registry-permissions.md), you define permissions that map roles, groups, or namespaces to specific resources (feature views, data sources, entities) and actions (read, write, delete). The server checks these permissions after authenticating the request but before executing the operation.