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).
File:
internal/service/oidc_service.go(lines 124, 197, 199, 206, 221, 228, 233, 274)Project: tinyauth
Severity: BUG • Confidence: high • Slug:
other-dead-codeFinding
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 publicKeyover 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
publicKeyshows 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 fromservice.privateKey.PublicKeydirectly. 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).