ppoppo-token 0.2.0

//! M68 — id_token c_hash binding (OIDC Core 1.0 §3.3.2.11).
//!
//! Mirror of M67 for the authorization-code axis: when a hybrid response
//! carries both an id_token and an authorization code at the redirect_uri,
//! the id_token's `c_hash` claim binds the two. An attacker cannot swap
//! in a stolen code without either forging the id_token or stripping the
//! binding.
//!
//! ── Why a separate module from `check_at_hash` ──────────────────────────
//!
//! Codebase convention is one mitigation row, one file (see
//! `check_nonce.rs`, `check_replay.rs`, `check_session.rs`). The two
//! checks share cryptography via `engine::hash_binding` but read
//! different `VerifyConfig` fields and emit different `AuthError`
//! variants, so the wiring layer stays separate. Merging them would
//! force one entry-point to carry per-claim conditional logic and would
//! make a future divergence (e.g. M68-specific timing or codec rule)
//! costly to introduce.
//!
//! Opt-in semantics identical to M67: engine inspects `c_hash` only when
//! the verifier supplied an expected authorization code via
//! `VerifyConfig::with_authorization_code_binding`.

use crate::engine::hash_binding::{self, HashBindingError};
use crate::id_token::{AuthError, VerifyConfig};

pub(crate) fn run(
    payload: &serde_json::Value,
    cfg: &VerifyConfig,
) -> Result<(), AuthError> {
    let Some(expected) = cfg.expected_authorization_code.as_deref() else {
        return Ok(());
    };
    hash_binding::verify_match(payload, "c_hash", expected.as_bytes()).map_err(|e| match e {
        HashBindingError::ClaimMissing => AuthError::CHashMissing,
        HashBindingError::Mismatch => AuthError::CHashMismatch,
    })
}