Principle:ClickHouse ClickHouse HTTP Authentication

ClickHouse_ClickHouse Implementation:ClickHouse_ClickHouse_Poco_HTTPDigestCredentials Implementation:ClickHouse_ClickHouse_Poco_HTTPAuthenticationParams Implementation:ClickHouse_ClickHouse_Poco_OAuth10Credentials

Purpose

Defines the principles behind HTTP authentication mechanisms used in the Poco networking library within ClickHouse. HTTP authentication enables clients and servers to establish identity through challenge-response protocols embedded in HTTP headers. The library supports multiple schemes including Basic, Digest, and OAuth 1.0.

Theoretical Basis

HTTP authentication (RFC 7235) follows a challenge-response model:

1. The server responds with a `401 Unauthorized` status and a `WWW-Authenticate` header specifying the acceptable authentication scheme(s).
2. The client includes an `Authorization` header in subsequent requests containing credentials formatted according to the chosen scheme.
3. The server validates the credentials and grants or denies access.

Basic Authentication (RFC 7617)

Credentials are the Base64 encoding of `username:password`. This provides no confidentiality without TLS.

Digest Authentication (RFC 7616)

Uses a challenge nonce from the server. The client computes a hash (typically MD5) over the username, password, nonce, HTTP method, and URI. This avoids transmitting the password in cleartext.

OAuth 1.0 (RFC 5849)

A token-based delegation protocol where:

• The consumer key and consumer secret identify the application.
• The token and token secret represent the user's authorization.
• Requests are signed using HMAC-SHA1 over a signature base string composed of the HTTP method, request URI, and sorted, percent-encoded parameters.
• A unique nonce and timestamp prevent replay attacks.
• The signature is transmitted in the `Authorization` header alongside the OAuth parameters.

Key Properties

• Challenge-response model: The server declares supported schemes; the client selects one and responds with appropriate credentials.
• Scheme extensibility: The HTTP `Authorization` header supports any authentication scheme identified by its token prefix.
• Signature-based integrity: OAuth 1.0 signs the request parameters, providing both authentication and request integrity without encrypting the payload.
• Replay protection: OAuth 1.0 uses nonces and timestamps; Digest auth uses server-issued nonces with optional nonce counts.
• Credential separation: OAuth 1.0 separates application credentials (consumer key/secret) from user credentials (token/token secret), enabling delegated authorization.

Related RFCs

• RFC 7235 -- Hypertext Transfer Protocol: Authentication
• RFC 7617 -- The 'Basic' HTTP Authentication Scheme
• RFC 7616 -- HTTP Digest Access Authentication
• RFC 5849 -- The OAuth 1.0 Protocol