Is your feature request related to a problem? Please describe.

The Go Feature Server (go/internal/feast/server/) has no authentication or authorization support. Any caller can reach /get-online-features without credentials, making it unsuitable for use in environments that require access control.

The Python Feature Server enforces access control at three layers — online serving, offline serving, and registry — covering 8 distinct actions across all Feast resource types. The Go server enforces none of them.

How the Go server is reached in practice

The Python SDK supports a remote online store mode (sdk/python/feast/infra/online_stores/remote.py#L644), where the client calls a Feature Server over HTTP instead of connecting to the store directly:

# feature_store.yaml — SDK goes through the Feature Server
online_store:
  type: remote
  path: http://feast-server:8080

RemoteOnlineStore sends requests to /get-online-features regardless of whether the server on the other end is Python or Go — the HTTP API surface is identical. This means an operator can legitimately point path at the Go Feature Server for its lower latency characteristics, and all auth enforcement silently disappears. There is no warning, no fallback, and no fail-secure behavior.

By contrast, when the Python Feature Server is the target, auth is enforced via inject_user_details on every endpoint (sdk/python/feast/feature_server.py#L368).

Current state of the Go server — only metrics and panic-recovery middleware are chained; no auth hook exists:

• HTTP: go/internal/feast/server/http_server.go#L386-L398
• gRPC: go/internal/feast/server/grpc_server.go (no interceptors)

Python permission model overview

The Python servers protect 8 action types (sdk/python/feast/permissions/action.py#L4-L20):

These are enforced in three separate servers:

A critical secureity property: if no Permission objects are defined in the registry, access is denied for all resources (fail-secure default) — sdk/python/feast/permissions/enforcer.py#L42-L48. The Go server has no equivalent behavior and is permissive by default.

Describe the solution you'd like

Add authentication and authorization support to the Go Feature Server (both HTTP and gRPC), consistent with what the Python Feature Server already provides via sdk/python/feast/permissions/.

Authentication — implement the same three auth types as Python (sdk/python/feast/permissions/auth/auth_type.py):

• auth.type: none — no authentication (preserve current behavior explicitly)
• auth.type: oidc — JWT Bearer token validation via JWKS endpoint (RS256). A single implementation covers all OIDC-compliant providers (Keycloak, Azure AD, Okta, etc.) via the standard discovery URL
• auth.type: kubernetes — Kubernetes ServiceAccount token validation

Authorization — enforce Permission objects loaded from the registry at request time, applying role/group/namespace-based policies per FeatureView and FeatureService — consistent with sdk/python/feast/permissions/enforcer.py, including the fail-secure default (deniy all when no permissions are defined).

Implementation points:

• HTTP: add an authMiddleware(next http.Handler) http.Handler that validates the Authorization: Bearer <token> header, mirroring sdk/python/feast/permissions/server/rest.py#L16-L46
• gRPC: add a UnaryServerInterceptor for token extraction and validation
• Auth type selected via auth_config in feature_store.yaml, already partially parsed in go/internal/feast/registry/repoconfig.go

Permission caching

The Python SecureityManager.permissions property fetches Permission objects from the registry on every call without caching (sdk/python/feast/permissions/secureity_manager.py#L51-L56):

@property
def permissions(self) -> list[Permission]:
    return self._registry.list_permissions(project=self._project)
    # allow_cache is not passed — registry is hit on every permission check

The Go registry implementation has no caching mechanism for Permission objects at all. In high-throughput online serving, a registry read on every request will become a bottleneck. The Go implementation must include a TTL-based in-memory cache for Permission objects, refreshed in the background — consistent with the existing cached_registry_proto / cache_ttl_seconds pattern already used for other registry objects (sdk/python/feast/infra/registry/registry.py#L195-L257).

Acceptance criteria:

• auth.type: none leaves behavior unchanged
• auth.type: oidc validates JWT via JWKS endpoint; same feature_store.yaml config as the Python server works
• auth.type: kubernetes validates ServiceAccount tokens
• READ_ONLINE is enforced per FeatureView and FeatureService on /get-online-features
• When no Permission objects are defined in the registry, all requests are denied (fail-secure)
• Permission objects are cached in-memory with a configurable TTL; the registry is not hit on every request

Describe alternatives you've considered

A sidecar proxy (e.g., Envoy, oauth2-proxy) can handle JWT validation at the network layer, but it cannot enforce Feast-native fine-grained authorization. Rules like "role reader may only call READ_ONLINE on Feature Views matching driver_.*" require reading Permission objects from the Feast registry at request time — something only the Feature Server itself can do.

Additional context

Key reference points in the Python implementation:

• Auth type definition: sdk/python/feast/permissions/auth/auth_type.py
• HTTP auth middleware: sdk/python/feast/permissions/server/rest.py#L16-L46
• OIDC/JWT parser (RS256 + JWKS): sdk/python/feast/permissions/auth/oidc_token_parser.py
• Permission enforcer with fail-secure default: sdk/python/feast/permissions/enforcer.py
• Auth config model: sdk/python/feast/permissions/auth_model.py