Score API authentication on mechanism, credential entropy, rotation, replay protection, secret storage, MFA and lockout.
The mechanism carries the largest weight because it decides what an attacker needs to steal: a private key that never leaves the client, a short-lived token, or a static string that works forever. Entropy, rotation and storage then determine how likely that credential is to leak and how long a leak stays useful. Most API breaches are not exploits but credentials — a key committed to a repository, a token in a log, a shared secret that has not rotated since the integration went live.
API Authentication Strength
Authentication score = mechanism (28 mTLS … 0 none) + entropy score (10 at ≥256 bits … 0 below 32) + rotation score (10 at ≤30 days … 0 above a year) + 12 replay protection + 12 secret storage + 10 scoping + 10 MFA on issuance + 8 lockout = 100.
Authentication score = mechanism (28 mTLS … 0 none) + entropy score (10 at ≥256 bits … 0 below 32) + rotation score (10 at ≤30 days … 0 above a year) + 12 replay protection + 12 secret storage + 10 scoping + 10 MFA on issuance + 8 lockout = 100. The mechanism carries the largest weight because it decides what an attacker needs to steal: a private key that never leaves the client, a short-lived token, or a static string that works forever. Entropy, rotation and storage then determine how likely that credential is to leak and how long a leak stays useful.
Most API breaches are not exploits but credentials — a key committed to a repository, a token in a log, a shared secret that has not rotated since the integration went live.
This calculator takes 8 inputs: Authentication mechanism, Credential entropy, Nonce and timestamp replay protection, Credential rotation interval, Least-privilege scopes per credential, Secrets held in a KMS or vault, never in source, MFA on the human path that issues credentials, Failed-attempt throttling or lockout. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
For server-to-server calls, usually yes. The signing key never travels, so a captured request cannot be replayed against another endpoint, and adding a nonce and timestamp to the signed payload blocks replay entirely. Bearer tokens are simpler and fine when they are short-lived and sent only over TLS.