[BUG] Loaded public key file is stored but never used; admins can be misled into thinking they're configuring the JWT signing key #860

File: internal/service/oidc_service.go (lines 124, 197, 199, 206, 221, 228, 233, 274)
Project: tinyauth
Severity: BUG • Confidence: high • Slug: other-dead-code

Finding

NewOIDCService reads/loads/parses config.OIDC.PublicKeyPath into the publicKey field (lines 197-240, 274) but no code path ever references service.publicKey afterwards — a grep -n publicKey over the codebase shows zero downstream readers. Every operation that needs the JWT verification key derives it from privateKey.Public() (e.g. GetJWK at lines 813-832, signer kid at lines 456-464). If an admin edits the configured public key file expecting the JWKS endpoint or token kid to change, nothing happens — they'll only know once a relying party can't verify a token. Worse, if the on-disk public key file drifts away from the private key file (operator error, partial restore from backup), tinyauth still serves the correct JWKS from the private key but the operator believes the public file is canonical, leading to extended trust-on-the-wrong-thing during incident response.

Recommendation

Either remove the publicKey field and the PublicKeyPath config option entirely (since the public key is always derived from the private key), or use the loaded publicKey as the canonical key for JWKS/kid computation and fail loudly at startup when it doesn't match privateKey.Public(). Don't silently load and discard.

Revalidation

Verdict: true-positive

Confirmed. A grep over /home/stavros/working-on/tinyauth/internal for publicKey shows it written in oidc_service.go (lines 197, 199, 206, 207, 221, 228, 233, 274) but never read after assignment to the struct field at line 274. GetJWK (lines 813-832) and generateIDToken (lines 456-464) both derive the public key from service.privateKey.PublicKey directly. The PublicKeyPath config option is required (line 154-157) and the file is loaded/parsed, then discarded. An operator editing the public-key file expecting the JWKS endpoint or kid to change will be silently confused, and a backup-restore that puts an out-of-sync public key on disk will look authoritative while tinyauth keeps using the private key's derived public key. The recommendation (drop the field, or fail loudly when the on-disk public key doesn't match privateKey.Public()) is sound. Severity BUG (not a security vulnerability per se, but a real defect with operational/security implications).