securitydept_token_set_context/lib.rs
1//! # securitydept-token-set-context
2//!
3//! **Unified product surface** for the securitydept OIDC mode family,
4//! symmetric with the frontend `token-set-context-client` TS SDK.
5//!
6//! ## Canonical public surface
7//!
8//! | Module | Description |
9//! |---|---|
10//! | [`backend_oidc_mode`] | **Canonical** — unified backend OIDC capability framework (capabilities, config, runtime, service, transport) |
11//! | [`frontend_oidc_mode`] | Frontend OIDC — config, runtime, service, cross-boundary contracts |
12//! | [`access_token_substrate`] | Cross-mode shared substrate: resource-server verification, propagation, forwarder |
13//! | [`orchestration`] | Cross-mode shared config, OIDC client, provider infrastructure |
14//! | [`models`] | Shared auth-state data models |
15//!
16//! ## Mode relationship
17//!
18//! - `backend-oidc` is the canonical unified surface. It parameterizes runtime
19//! behaviour through capability axes (`refresh_material_protection`,
20//! `metadata_delivery`, `post_auth_redirect`). Adopters configure the axes
21//! directly — no preset indirection needed.
22//! - `frontend-oidc` has no backend OIDC client runtime — the browser owns the
23//! full OIDC lifecycle. This module provides formal config, runtime, and
24//! service patterns alongside cross-boundary contracts describing what the
25//! backend expects from frontend-produced tokens.
26//!
27//! ## Entry point
28//!
29//! Adopters should enter via [`backend_oidc_mode`] for new integrations,
30//! use [`orchestration`] for shared config resolution, and
31//! [`access_token_substrate`] for token verification and propagation.
32
33// --- Canonical public modules ---
34
35pub mod access_token_substrate;
36pub mod backend_oidc_mode;
37pub mod cross_mode_config;
38pub mod frontend_oidc_mode;
39pub mod models;
40pub mod orchestration;
41
42#[cfg(test)]
43mod tests;