Credential Types and Selection

In the architecture of authentication and authorization, a credential serves as the digital evidence a subject presents to prove their identity, gain access to protected resources, or act on behalf of another entity. Whether it is a secret string, a cryptographic key, a digital certificate, or a signed assertion from an Identity Provider (IdP), the goal remains the same: establishing trust.

Selecting the right credential is not about picking a specific product, but about applying a strategic framework that balances Risk, Scenario, and Lifecycle.
To understand credentials, we must first categorize them by the "factors" they represent. Robust security models rely on combining these distinct categories to implement Multi-Factor Authentication (MFA).

• Knowledge Factors (Something you know): Information that the user must recall, such as passwords, PINs, or passphrases.
• Possession Factors (Something you have): Physical or digital assets, such as hardware security keys (YubiKeys), smart cards, mobile devices, or client-side certificates.
• Inherence Factors (Something you are): Biological traits, including fingerprints, facial recognition, or voice patterns.

Crucial Note: True MFA requires the combination of different factors. Requiring two different passwords is not MFA; it is simply two instances of a knowledge factor.

Categorizing Credentials by Nature and Usage

Beyond the authentication factors, credentials can be classified by their technical behavior and the entity using them.

Static vs. Dynamic

• Static Credentials: Long-lived secrets such as traditional passwords, API keys, or service account keys. These are easier to deploy but carry higher risk if leaked.
• Dynamic Credentials: Short-lived or single-use tokens, such as One-Time Passwords (OTP), ephemeral access tokens, or temporary certificates. These significantly reduce the window of opportunity for an attacker.

Symmetric vs. Asymmetric

• Symmetric Credentials: Both parties share the same secret (e.g., a Pre-Shared Key or some API keys). The primary risk is that the secret must be transmitted or stored on both ends.
• Asymmetric Credentials: Based on public-key cryptography. The subject holds a private key to sign a challenge, and the verifier uses a public key to validate it (e.g., FIDO2/WebAuthn, mTLS). The private key never leaves the owner's device.

Human vs. Machine

• Human Credentials: Designed for usability, memorability, and recovery. The focus is on the user experience (UX) and preventing social engineering.
• Machine Credentials: Designed for automation, high-frequency rotation, and the principle of least privilege. The focus is on secure storage (vaults) and programmatic lifecycle management.

Credential Type Overview

Dimensions for Selecting the Right Credential

When designing an authentication flow, evaluate your choices against these eight dimensions:

1. Security Strength: Can it resist phishing, replay attacks, and Man-in-the-Middle (MitM) attacks? Is it bound to a specific device or network context?
2. User Experience (UX): How frictionless are the enrollment, authentication, and recovery processes?
3. Lifecycle Management: How long is the credential valid? Does it support automatic rotation?
4. Revocability: Can the credential be revoked centrally and instantaneously? What is the propagation delay for revocation?
5. Binding and Scope: Is the credential bound to a specific user, device, or IP? Does it follow the principle of least privilege?
6. Interoperability: Does it adhere to industry standards (e.g., OAuth 2.0, FIDO2) to ensure compatibility across platforms?
7. Operational Cost: What are the costs associated with hardware procurement, deployment, and ongoing support?
8. Observability: Can every issuance, usage, and failure be audited and monitored for anomalies?

Scenario-Based Recommendations

Public Web and Mobile Applications

The baseline should be Password + MFA. However, the industry is shifting toward Passkeys (WebAuthn) to eliminate passwords entirely and provide native phishing resistance. Session management should be handled via secure, HttpOnly cookies or short-lived tokens.

Enterprise Single Sign-On (SSO)

Leverage Federated Identity. Use an Identity Provider (IdP) to handle the primary authentication and issue signed SAML or OIDC assertions. This centralizes revocation and reduces the attack surface across multiple applications.

Service-to-Service (API to API)

Prioritize mTLS (mutual TLS) or short-lived workload identities. Avoid long-lived API keys; if they must be used, ensure they are restricted by IP address and rotated frequently via a secret management vault.

CI/CD Pipelines

Avoid hard-coding static secrets in pipeline configurations. Use OIDC Federation to allow the CI/CD runner to exchange a short-lived identity token for temporary cloud credentials.

IoT and Edge Computing

Device Certificates are the gold standard. In highly constrained environments where asymmetric encryption is computationally impossible, use Pre-Shared Keys (PSK), but ensure they are unique per device.

Credential Selection Matrix