Validating Authentication Implementations

Overview

Review authentication source/configuration and use the bundled local CLIs for explicit declarations, JWT verification profiles and password-policy checks. Keep input evidence, cryptographic verification and deployed enforcement separate.

Prerequisites

• Identify the user's target project. ${CLAUDE_SKILL_DIR} locates this skill's resources; it does not select the target codebase.
• Use Python 3.11+ for the supported verification environment. Local declaration review and token inspection use the standard library. Verification requires supported PyJWT and the pinned optional backend prerequisites listed in scripts/requirements.txt.
• Keep tokens, keys, candidates and configuration in private files. Confirm the intended local inputs and output destination. Script execution uses the operator's normal permission boundaries; scoped grants do not preapprove arbitrary shell commands or installing dependencies.
• Do not make live login, IdP, token refresh/revocation or breach-service calls. These helpers do not fetch JWKS, install tools, modify the audited project or provide an OS sandbox.

Instructions

1. Use Glob to locate relevant project files, Read to inspect them and Grep to find authentication call sites without printing credential values. Record which flows and controls were actually reviewed; absence of a matching string does not prove absence of a control.
2. For configuration review, supply explicit JSON to authentication_check.py. It checks declared JWT, HTTPS web OAuth, session and API-key settings. Unknown methods/fields and malformed types are incomplete. Missing optional password, MFA or lockout sections are unassessed; configuration success never proves implementation, deployment or server-side enforcement.
3. For a local JWT, prefer --file. Default inspection reveals controlled metadata and supplied temporal problems, omits raw payload/signature data and returns unverified/nonzero. Decoding a claim is never authentication.
4. To verify a JWT, independently select a trusted local key file, one allowed algorithm, expected issuer and expected audience. Supply all four explicitly. The tool supports the existing twelve HS/RS/PS/ES routes through maintained PyJWT, requires expiration, checks provided temporal claims and rejects unsupported critical semantics. It never derives trust from received alg, kid, key URLs or embedded keys. Algorithm labels and key length do not prove key entropy, ownership or suitable trust for a real service.
5. Inspect the verification status and exit code. Missing/old back…