Context
The Go client supports multiple auth methods through a CredentialsProvider interface. PR #80 had the right idea with an AuthProvider interface but needs refinement. This also covers the Chroma Cloud authentication flow.
Requirements
AuthProvider Interface
public interface AuthProvider {
/** Apply auth credentials to the given request headers. */
void applyAuth(Map<String, String> headers);
}
Design: auth providers modify a mutable headers map. This is simpler than returning headers or wrapping requests.
Built-in Implementations
// Token-based (Authorization: Bearer <token>)
public final class TokenAuth implements AuthProvider {
public static TokenAuth of(String token) { ... }
}
// Basic Auth (Authorization: Basic base64(user:pass))
public final class BasicAuth implements AuthProvider {
public static BasicAuth of(String username, String password) { ... }
}
// X-Chroma-Token header
public final class ChromaTokenAuth implements AuthProvider {
public static ChromaTokenAuth of(String token) { ... }
}
Client Builder Integration
// Explicit auth provider
ChromaClient.builder()
.baseUrl("http://localhost:8000")
.auth(BasicAuth.of("admin", "secret"))
.build();
// Convenience: API key sets X-Chroma-Token (Chroma Cloud)
ChromaClient.builder()
.baseUrl("https://api.trychroma.com")
.apiKey("chroma-api-key")
.tenant("my-tenant")
.database("my-db")
.build();
Custom Headers
For non-standard auth or additional headers:
ChromaClient.builder()
.baseUrl("http://localhost:8000")
.defaultHeaders(Map.of("X-Custom-Auth", "value"))
.build();
Design Decisions
applyAuth(Map<String, String> headers) — provider mutates headers map, keeps the interface simple
- Static factory methods —
TokenAuth.of(token), not new TokenAuth(token)
apiKey() on the builder — syntactic sugar that creates a ChromaTokenAuth internally
- No auth is the default — no
NoAuthProvider sentinel object needed; just don't set auth
Acceptance Criteria
Supersedes
Context
The Go client supports multiple auth methods through a
CredentialsProviderinterface. PR #80 had the right idea with anAuthProviderinterface but needs refinement. This also covers the Chroma Cloud authentication flow.Requirements
AuthProvider Interface
Design: auth providers modify a mutable headers map. This is simpler than returning headers or wrapping requests.
Built-in Implementations
Client Builder Integration
Custom Headers
For non-standard auth or additional headers:
Design Decisions
applyAuth(Map<String, String> headers)— provider mutates headers map, keeps the interface simpleTokenAuth.of(token), notnew TokenAuth(token)apiKey()on the builder — syntactic sugar that creates aChromaTokenAuthinternallyNoAuthProvidersentinel object needed; just don't set authAcceptance Criteria
AuthProviderinterface definedTokenAuth,BasicAuth,ChromaTokenAuthimplementationsauth()andapiKey()methodsdefaultHeaders()support on client builderSupersedes