RUSTSEC-2026-0258 (h2 unbounded empty DATA frames) used to reach this framework through the optional actix-integration feature: actix-web with its default http2 feature pulls actix-http, which requires h2 ^0.3.27, and no patched 0.3 release of h2 exists (the fix is h2 >= 0.4.16).

This crate now depends on actix-web with default-features = false (only macros), so h2 0.3.x is no longer in this crate's dependency graph, for any feature combination (cargo tree -i h2 shows only 0.4.x). cargo-deny bans any h2 < 0.4.16.

• If your application enables actix-web's http2 feature itself (for example by depending on actix-web with default features), it takes h2 0.3.x with it, and the advisory applies to your server exactly as for any actix-web application. This is not something the framework can change; track the advisory and actix-web's repository for an h2 0.4 line.
• The integration itself only provides an AuthMiddleware for your own actix_web::HttpServer; it never runs a server.

RUSTSEC-2023-0071 (Marvin Attack on RSA, a timing side-channel in RSA PKCS#1 v1.5 decryption) previously affected this framework via several paths: jsonwebtoken's RS*/PS* JWT support, the JARM RSA-OAEP JWE path, and MySQL storage's rsa dependency through SQLx's caching_sha2_password auth-plugin support. The JWT and JARM paths were rewritten against aws-lc-rs (not subject to this advisory). MySQL storage (mysql-storage) has been removed from this crate entirely, closing that path for good -- use postgres-storage, sqlite-storage, or redis-storage instead. See CHANGELOG.md for the migration note if you were relying on MySQL support.

Security fixes are released on all three active lines, so use the newest release of the line you are on:

Versions that fall inside a published advisory are yanked from crates.io. Do not pin a yanked version, and do not pin one older than the first fixed release listed in the advisory that applies to your line. The advisories are listed at https://github.com/ciresnave/auth-framework/security/advisories; the releases that fixed the most recent ones are 0.4.29, 0.5.0-rc51 and 0.6.0-rc85 (GHSA-jr9j-g3xj-q9x8: fixed signing keys in the JARM, JWT introspection and default SAML components; it covers >=0.4.0,<0.4.29, >=0.5.0-rc1,<0.5.0-rc51 and >=0.6.0-rc41,<0.6.0-rc85). The one before it, GHSA-9r7g-3hh2-8x65 (default signing secret), is fixed in the same releases. The next fixes are in CHANGELOG.md.

The Auth Framework is designed with security as a primary concern. However, security is a shared responsibility between the library maintainers and the users implementing it.

This library provides:

• Secure Token Management: JWT tokens with proper signing and validation
• Password Hashing: Argon2 and bcrypt implementations
• Rate Limiting: Protection against brute force attacks
• Session Management: Secure session handling with expiration
• Constant-Time Operations: Protection against timing attacks
• Input Validation: Comprehensive input sanitization
• Audit Logging: Security event tracking

When using this library, ensure:

• Secret Management: Never hardcode secrets in your application
• HTTPS: Always use HTTPS in production
• Key Rotation: Regularly rotate signing keys and secrets
• Dependency Updates: Keep all dependencies updated
• Configuration Review: Regularly review security configurations
• Monitoring: Monitor for suspicious authentication patterns

We take security vulnerabilities seriously. If you discover a security issue:

Instead, please:

1. Email: Send details to ciresnave@gmail.com
2. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)
3. Encrypt: Use PGP if possible (key available on request)

1. Acknowledgment: We will acknowledge receipt within 48 hours
2. Assessment: We will assess the vulnerability within 5 business days
3. Fix: We will work on a fix and coordinate disclosure
4. Release: Security fixes will be released as soon as possible
5. Credit: We will credit the reporter unless they prefer to remain anonymous

// Use strong secrets
let config = AuthConfig::new()
    .security(SecurityConfig::secure()) // Use secure defaults
    .rate_limiting(RateLimitConfig::new(100, Duration::from_secs(60)));

// Good: Use environment variables
let secret = std::env::var("JWT_SECRET").expect("JWT_SECRET must be set");

// Bad: Hardcoded secret
let secret = "hardcoded-secret"; // DON'T DO THIS

// Use secure storage in production
let storage = RedisStorage::new("rediss://user:pass@redis.example.com:6380")?;

// Not recommended for production
let storage = MemoryStorage::new(); // Only for development/testing

• No hardcoded secrets or passwords
• Proper input validation
• Constant-time operations for sensitive comparisons
• No sensitive data in logs
• Proper error handling without information leakage
• Secure defaults in configurations
• Updated dependencies

• Test with invalid/malformed inputs
• Test rate limiting functionality
• Test token expiration and revocation
• Test permission boundaries
• Test against common attack vectors

• User credentials and authentication data
• Session tokens and API keys
• User personal information
• System configuration and secrets

• Credential Stuffing: Automated attempts using stolen credentials
• Brute Force: Systematic password guessing attempts
• Session Hijacking: Stealing or intercepting session tokens
• Privilege Escalation: Gaining unauthorized access levels
• Timing Attacks: Exploiting time differences in operations
• Injection Attacks: Malicious input exploitation

• Rate limiting and account lockout
• Strong password requirements
• Secure session management
• Proper authorization checks
• Constant-time operations
• Input validation and sanitization

This library aims to help users meet common security standards:

• OWASP Top 10: Address common web application vulnerabilities
• NIST Cybersecurity Framework: Implement security controls
• PCI DSS: Payment card industry security standards
• GDPR: Data protection compliance features

We regularly audit and update dependencies. Security-sensitive dependencies include:

• ring: Cryptographic operations (HMAC, random generation, key agreement)
• jsonwebtoken: JWT implementation
• argon2: Password hashing
• sha2: SHA-256/SHA-512 digests
• hmac: HMAC constructions (backchannel logout, RADIUS)
• md-5: MD5 for RADIUS RFC 2865 protocol compliance only
• aes-gcm: AES-GCM authenticated encryption
• redis: Storage backend
• tokio: Async runtime

The framework includes a SAML integration layer (src/api/saml.rs) that implements portions of the WS-Security and SAML 2.0 specifications. These legacy SOAP/XML-based protocols mandate SHA-1 as a required digest algorithm in their standards-defined signature and reference validation flows.

Status: SHA-1 is used exclusively for WS-Security XML digital signature canonicalization, where it is required by the protocol specification itself. It is not used for:

• Password storage (Argon2 / bcrypt)
• JWT signing (HMAC-SHA256 or RS256)
• Any application-controlled cryptographic operation

Risk assessment: Low. The SHA-1 usage is confined to the SAML/WS-Security XML layer where:

1. The attacker would need to forge a signed SAML assertion
2. SHA-1 collision attacks require impractical computation on XML structures
3. Modern IdPs increasingly support SHA-256 variants; configure your IdP to prefer http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 where possible

Mitigation path: When your SAML Identity Provider supports SHA-256 digests (http://www.w3.org/2001/04/xmlenc#sha256), configure it to use them. A future release will add configurable algorithm preference to the SAML handler.

The following protocol implementations have known limitations that users should be aware of:

Several protocol modules provide partial or stub implementations that are not yet suitable for production use without additional cryptographic verification:

• Kerberos/SPNEGO: AP-REQ validation performs basic ASN.1 tag checking only. Full Kerberos ticket validation requires integration with a KDC. The module returns an error indicating this limitation.
• SAML Assertions: XML signature verification uses SHA-1 per protocol specification. No full XML canonicalization (C14N) or signature chain validation is implemented.
• WS-Federation: security tokens are accepted only as SAML assertions whose signature verifies under a key or certificate thumbprint the operator configured. JWT security tokens are rejected, because their signature is not verified here; use a dedicated JWT validator for them.
• WS-Trust: Issued tokens are stored in-memory only. They are lost on restart and not shared across instances. Production deployments should integrate with the StorageBackend KV layer.
• GNAP: implements grant negotiation and transaction state management, but a dpop proof method is accepted by name only: no DPoP proof is validated (src/protocols/gnap.rs). Tracked in docs/ROADMAP.md.
• OpenID4VP: resolves did:key and did:web identifiers and verifies JWS signatures (EdDSA, ES256) against the resolved key. Coverage of other DID methods and credential formats is narrower than the specification; see COMPATIBILITY.md.
• UMA 2.0: Implements resource registration, permission tickets, and basic policy evaluation. Does not include a full claims-gathering interaction flow.

The RADIUS client (src/protocols/radius.rs) uses MD5 as required by RFC 2865. MD5 is known to be cryptographically weak, but its use is mandated by the RADIUS protocol specification. Mitigate by:

1. Using RADIUS over IPsec or a secure tunnel
2. Migrating to RADIUS/TLS (RFC 6614) when infrastructure supports it
3. Using strong shared secrets (32+ random bytes)

Security-related changes will be clearly marked in the changelog with the [SECURITY] tag.

For security questions or concerns:

• Email: ciresnave@gmail.com
• PGP Key: Available on request

We thank the security researchers and community members who help keep this project secure.

This security policy is subject to updates. Please check regularly for the latest version.