# DS2API Authentication Modes for DeepSeek Accounts: 3 Methods Explained

> Discover DS2API authentication modes for DeepSeek accounts. Learn about token passing, server-side config-token, and bypass modes. Secure your API access easily.

- Repository: [CJACK./ds2api](https://github.com/CJackHwang/ds2api)
- Tags: deep-dive
- Published: 2026-04-26

---

**DS2API supports three distinct authentication strategies for DeepSeek accounts: direct token passing, server-side config-token management with automatic refresh, and a no-authentication bypass mode for internal endpoints.**

The `CJackHwang/ds2api` repository implements a flexible authentication layer that allows developers to integrate DeepSeek API access through different security models. By leveraging the `RequestAuth` structure defined in the source code, you can choose between client-supplied credentials, managed account tokens, or disabled authentication depending on your specific infrastructure requirements.

## Direct Token Authentication

In **direct token mode**, the client supplies a DeepSeek access token that DS2API forwards unchanged to every DeepSeek request. This mode accepts tokens via the `api_key` query parameter or an `Authorization: Bearer <token>` header.

The implementation relies on the `DeepSeekToken` field within the `RequestAuth` struct. According to the source code in [`internal/auth/request.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/auth/request.go) (lines 26-29), this field stores the plain token string provided by the client:

```go
type RequestAuth struct {
    DeepSeekToken  string
    UseConfigToken bool
    AccountID      string
}

```

The `TestDirectToken` test case in [`internal/auth/request_test.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/auth/request_test.go) (lines 40-45) validates that the token is taken verbatim from the incoming request and used without modification. This approach is ideal when your clients already possess valid DeepSeek access tokens and you want DS2API to act as a transparent proxy.

## Config-Token (Account-Based) Authentication

**Config-token mode** delegates token management to the DS2API server itself. When `UseConfigToken` is set to `true` and an `AccountID` is provided, DS2API fetches a fresh DeepSeek access token on-the-fly using pre-configured client credentials, caches it, and automatically refreshes it upon expiration.

This mode uses the same `RequestAuth` structure but activates the server-side token flow. As shown in [`internal/auth/request.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/auth/request.go) (lines 26-28), the relevant fields are:

```go
UseConfigToken bool   // Activates server-side token management
AccountID      string // Identifies which configured account to use

```

The automatic refresh behavior is demonstrated in `TestConfigTokenRefresh` within [`internal/auth/request_test.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/auth/request_test.go) (lines 64-71). When the cached token expires, DS2API transparently obtains a new one using the stored client-id and client-secret from [`config.json`](https://github.com/CJackHwang/ds2api/blob/main/config.json), ensuring uninterrupted service without client intervention.

## No-Authentication Mode

For **internal admin or health-check endpoints**, DS2API supports running without any DeepSeek authentication. When the request's mode is set to `"none"`, DeepSeek-specific calls are bypassed entirely.

This check occurs in the OpenAI-compatible chat handler at [`internal/httpapi/openai/chat/handler_chat.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/httpapi/openai/chat/handler_chat.go) (lines 116-118), where the code explicitly skips token handling:

```go
if mode == "none" {
    // Skip DeepSeek token handling for admin/internal endpoints
}

```

This mode is useful for diagnostic routes, metrics endpoints, or scenarios where you need to test DS2API's HTTP layer without consuming DeepSeek API quota.

## Implementation Guide

You can construct `RequestAuth` instances for each mode as follows:

```go
import "github.com/CJackHwang/ds2api/internal/auth"

// Mode 1: Direct token from client
authDirect := &auth.RequestAuth{
    DeepSeekToken:  "sk-deepseek-abc123",
    UseConfigToken: false,
}

// Mode 2: Server-managed token with automatic refresh
authConfig := &auth.RequestAuth{
    UseConfigToken: true,
    AccountID:      "production-account",
    // DeepSeekToken auto-populated after refresh
}

// Mode 3: No authentication (bypass mode)
authNone := &auth.RequestAuth{
    // All token fields empty; DeepSeek calls skipped when mode == "none"
}

```

Each mode provides distinct advantages: direct tokens offer simplicity for existing credential holders, config-tokens provide enterprise-grade token lifecycle management, and the none mode enables maintenance operations without API dependencies.

## Summary

- **Direct token mode** forwards client-supplied DeepSeek tokens verbatim, suitable when clients manage their own API credentials.
- **Config-token mode** enables server-side token fetching and automatic refresh using configured accounts, stored in [`internal/auth/request.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/auth/request.go) and validated through `TestConfigTokenRefresh`.
- **No-authentication mode** bypasses DeepSeek token requirements entirely for internal endpoints, implemented in [`internal/httpapi/openai/chat/handler_chat.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/httpapi/openai/chat/handler_chat.go) with the `mode == "none"` check.
- All modes rely on the `RequestAuth` struct defined in the `CJackHwang/ds2api` repository to standardize authentication handling across the proxy layer.

## Frequently Asked Questions

### How does DS2API handle token expiration in config-token mode?

When `UseConfigToken` is enabled and a request includes an `AccountID`, DS2API automatically fetches a fresh DeepSeek access token if the cached version has expired. This refresh logic is tested in [`internal/auth/request_test.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/auth/request_test.go) (lines 64-71), ensuring tokens remain valid without requiring client-side renewal logic.

### Can I use DS2API without a DeepSeek account?

Yes, by setting the request mode to `"none"` as implemented in [`internal/httpapi/openai/chat/handler_chat.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/httpapi/openai/chat/handler_chat.go) (lines 116-118). This bypasses all DeepSeek authentication requirements, though it restricts functionality to endpoints that don't require AI model access, such as health checks or administrative routes.

### What is the difference between direct token and config-token authentication?

**Direct token** authentication requires clients to provide their own DeepSeek API keys via headers or query parameters, which DS2API proxies directly. **Config-token** authentication stores client credentials server-side in [`config.json`](https://github.com/CJackHwang/ds2api/blob/main/config.json) and manages token acquisition and caching automatically, identified by an `AccountID` rather than exposing raw tokens to clients.

### Where are the authentication modes configured in the source code?

The authentication modes are implemented in three key locations: the `RequestAuth` struct definition in [`internal/auth/request.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/auth/request.go) (lines 26-29) handles direct and config-token fields, the test suite in [`internal/auth/request_test.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/auth/request_test.go) validates the token passing and refresh logic, and the bypass check resides in [`internal/httpapi/openai/chat/handler_chat.go`](https://github.com/CJackHwang/ds2api/blob/main/internal/httpapi/openai/chat/handler_chat.go) (lines 116-118) for the no-authentication mode.