Crate broadcast_auth 

Shared multi-scheme authentication for RTSP and HTTP clients and servers.

Auth is not transport-specific: RTSP, TS-over-HTTP, HLS-pull, and any other credentialed origin all face the same handful of schemes. This crate holds one Credentials model, one client-side challenge->response helper (respond/Authenticator), and one server-side challenge+verify type (Verifier), so rtsp-runtime, multimux’s HTTP input adapters, and multimux’s own shared output-auth middleware all answer/issue WWW-Authenticate challenges through the same code instead of re-implementing it per client or per origin.

Client vs. server

• Client (respond/Authenticator): given a WWW-Authenticate challenge received from a server, compute the Authorization value to answer it.
• Server (Verifier): given a configured credential, produce the WWW-Authenticate challenge to send on a 401 (Verifier::challenge), and check an incoming Authorization header against it (Verifier::verify).

Schemes

• Basic (RFC 7617) and Digest (RFC 7616) — the challenge-parse and response computation is delegated to the mature http_auth crate. RTSP reuses these verbatim (RFC 2326 §14/§16): only the uri differs (the RTSP request URI, not an HTTP URL).
• Bearer (RFC 6750) — no challenge round-trip is required; the Authorization value is always Bearer <token>.
• Forwarded (server-side only, Verifier::forwarded) — trusts a fronting reverse proxy that has already authenticated the caller and forwards the authenticated username in a configured header. No Credentials/challenge-response round-trip. See the Verifier module docs for the trust assumption.

Usage

For a single request:

use broadcast_auth::{respond, Credentials, RequestContext};

let value = respond(
    "Basic realm=\"cameras\"",
    &RequestContext::new("GET", "/stream"),
    Credentials::new("admin", "12345"),
)
.unwrap();
assert!(value.starts_with("Basic "));

Across a session (Digest’s nc must advance on every request — keep the Authenticator alive, don’t call respond per-request):

use broadcast_auth::{Authenticator, Credentials, RequestContext};

let mut auth = Authenticator::from_challenge(
    "Digest realm=\"cameras\", nonce=\"abc123\", qop=\"auth\"",
    Credentials::new("admin", "12345"),
)
.unwrap();
let first = auth
    .authorization(&RequestContext::new("DESCRIBE", "rtsp://cam/stream"))
    .unwrap();
let second = auth
    .authorization(&RequestContext::new("PLAY", "rtsp://cam/stream"))
    .unwrap();
assert_ne!(first, second, "nc must advance between requests");

Bearer needs no challenge at all:

use broadcast_auth::Credentials;

let creds = Credentials::bearer("mytoken");
assert_eq!(creds, Credentials::Bearer { token: "mytoken".into() });

Structs

Authenticator

Negotiates a challenge once, then answers every subsequent request in the session (RFC 7235 WWW-Authenticate/Authorization; RFC 2326 §14 for RTSP; RFC 6750 for Bearer).

RequestContext

The request fields the Digest response hash covers (RFC 7616 §3.4.1 / RFC 2326 §14): the method, the request URI, and — for qop=auth-int — the body. Also carries the request’s headers and transport peer address, so a server-side crate::Verifier scheme can see beyond the Authorization header — e.g. a reverse-proxy forwarded-auth scheme reading X-Forwarded-User/X-Forwarded-For (issue #663 extensibility wave part 1). Client-side use (crate::respond/crate::Authenticator) needs neither field; Self::new defaults both to empty/None.

Verifier

Challenges + verifies incoming requests against one configured Credentials (RFC 7235 origin-side auth) — see the module docs.

Enums

AuthResult

The outcome of Verifier::verify.

Credentials

Credentials for one of the supported auth schemes.

Error

Errors produced by challenge parsing / response computation.

Functions

respond

One-shot challenge->response: computes the Authorization value for a single request without keeping an Authenticator around.

Type Aliases

Result

Result alias for the crate’s fallible operations.