# MySQL & OIDC Library Trade-offs Analysis
## AuthFramework v0.3.0 - Comprehensive Comparison
*Analysis Date: August 14, 2025*
---
## Executive Summary
This document analyzes trade-offs between current libraries (SQLx + OpenIDConnect) and alternatives (mysql_async + custom OIDC) to resolve the RUSTSEC-2023-0071 RSA vulnerability while maintaining functionality and security.
**Key Finding**: Each approach has distinct advantages - current libraries provide comprehensive features but introduce RSA dependency, while alternatives offer security but require significant development investment.
---
## 🔍 Current vs Alternative: MySQL Libraries
### SQLx (Current) vs mysql_async
| **Security** | ❌ RSA v0.9.8 dependency (RUSTSEC-2023-0071) | ✅ No RSA dependency |
| **Multi-DB Support** | ✅ PostgreSQL, MySQL, SQLite unified API | ❌ MySQL-only |
| **Compile-time Checks** | ✅ Compile-time SQL verification | ❌ Runtime-only validation |
| **Performance** | ⚡ Very High (optimized for multi-DB) | ⚡⚡ Excellent (MySQL-specific) |
| **Feature Completeness** | ✅ Full SQL feature set | ✅ Full MySQL feature set |
| **Async Support** | ✅ Tokio-based | ✅ Tokio-based |
| **Connection Pooling** | ✅ Built-in r2d2 integration | ✅ Built-in async pool |
| **Maintenance** | ✅ LaunchBadge (active) | ✅ blackbeam (active) |
| **Community** | ⭐ 15k stars, large ecosystem | ⭐ 389 stars, MySQL-focused |
| **Learning Curve** | 📚 Moderate (unified API) | 📚 Low (MySQL-specific) |
### **Trade-off Analysis: MySQL Libraries**
#### **Advantages of Switching to mysql_async:**
✅ **Complete RSA Elimination**: Zero vulnerability exposure
✅ **Performance Optimized**: MySQL-specific optimizations
✅ **Smaller Dependency Tree**: Fewer transitive dependencies
✅ **Mature & Stable**: Well-established MySQL driver
✅ **Lower Attack Surface**: Fewer dependencies to audit
#### **Disadvantages of mysql_async:**
❌ **Database Lock-in**: Lose PostgreSQL/SQLite compatibility
❌ **No Compile-time Checks**: SQL errors only at runtime
❌ **API Differences**: Significant code refactoring required
❌ **Smaller Ecosystem**: Fewer community resources
❌ **Feature Gap**: May lack some SQLx convenience features
#### **Code Migration Impact:**
**Current SQLx Code:**
```rust
use sqlx::{Pool, MySql, Row};
async fn get_user(pool: &Pool<MySql>, id: i32) -> Result<Option<User>, sqlx::Error> {
let user = sqlx::query_as!(
User,
"SELECT id, username, email FROM users WHERE id = ?",
id
)
.fetch_optional(pool)
.await?;
Ok(user)
}
```
**mysql_async Equivalent:**
```rust
use mysql_async::{Pool, Row, from_row, params};
async fn get_user(pool: &Pool, id: i32) -> Result<Option<User>, mysql_async::Error> {
let mut conn = pool.get_conn().await?;
let result = conn.exec_first(
"SELECT id, username, email FROM users WHERE id = ?",
params!(id)
).await?;
Ok(result.map(|row: Row| {
from_row::<(i32, String, String)>(row)
.map(|(id, username, email)| User { id, username, email })
}).transpose()?)
}
```
**Migration Effort**: 🔨 **High** - Significant API differences, loss of compile-time checks
---
## 🔍 Current vs Alternative: OIDC Libraries
### OpenIDConnect (Current) vs Alternatives
| **Security** | ❌ RSA v0.9.8 dependency | ✅ No RSA (JWT focus) | ✅ Complete control |
| **Feature Completeness** | ✅ Full OIDC spec | ❌ JWT validation only | ⚡ Exactly what you need |
| **Standards Compliance** | ✅ RFC 6749, OpenID Core | ❌ Partial compliance | ⚡ Custom compliance |
| **Provider Support** | ✅ Google, Azure, Auth0, etc. | ❌ Manual configuration | ⚡ Custom per provider |
| **Flow Support** | ✅ All flows (auth code, implicit, etc.) | ❌ Token validation only | ⚡ Custom flows |
| **Token Management** | ✅ Full lifecycle | ✅ Validation only | ⚡ Custom lifecycle |
| **Development Time** | ✅ Days | ⚡ Days-Weeks | ❌ Months |
| **Maintenance** | ✅ Community maintained | ⚡ Limited maintenance | ❌ Your responsibility |
| **Flexibility** | ❌ Library constraints | ⚡ Validation constraints | ✅ Complete flexibility |
| **Security Audit** | ✅ Community reviewed | ⚡ Smaller community | ❌ Your responsibility |
### **Trade-off Analysis: OIDC Libraries**
#### **Option 1: Switch to oidc-jwt-validator**
**Advantages:**
✅ **No RSA Dependency**: Eliminates vulnerability
✅ **Focused Scope**: Does one thing well (JWT validation)
✅ **High Performance**: Optimized for JWT operations
✅ **Quick Migration**: Similar API patterns
**Disadvantages:**
❌ **Limited Functionality**: Only handles JWT validation
❌ **Manual OIDC Flow**: Must implement authorization flows manually
❌ **Provider Integration**: Manual configuration for each provider
❌ **Incomplete Solution**: Requires additional libraries for full OIDC
#### **Option 2: Custom OIDC Implementation**
**Advantages:**
✅ **Complete Control**: Implement exactly what you need
✅ **No External Vulnerabilities**: Control your own security surface
✅ **Optimized Performance**: No unnecessary features
✅ **Future-Proof**: Adapt to changing requirements
✅ **Deep Understanding**: Full knowledge of implementation
**Disadvantages:**
❌ **Massive Development Effort**: 3-6 months of development
❌ **Security Risk**: Crypto implementation is error-prone
❌ **Standards Compliance**: Complex to implement correctly
❌ **Maintenance Burden**: Ongoing security updates needed
❌ **Testing Complexity**: Extensive test coverage required
### **OIDC Implementation Complexity Analysis**
#### **What Custom OIDC Implementation Requires:**
**1. Core Protocol Implementation:**
```rust
// Authorization Code Flow
pub struct AuthorizationRequest {
pub client_id: String,
pub redirect_uri: String,
pub scope: String,
pub state: String,
pub code_challenge: String, // PKCE
pub code_challenge_method: String,
}
// Token Exchange
pub struct TokenRequest {
pub grant_type: String,
pub code: String,
pub redirect_uri: String,
pub client_id: String,
pub code_verifier: String, // PKCE
}
```
**2. JWT Operations (without RSA):**
```rust
use jsonwebtoken::{decode, encode, Header, Validation, DecodingKey, EncodingKey};
use ring::{signature, rand};
// Use Ed25519 or ECDSA instead of RSA
pub fn create_jwt_ed25519(claims: &Claims) -> Result<String, Error> {
let key_pair = signature::Ed25519KeyPair::generate_pkcs8(&rand::SystemRandom::new())?;
let encoding_key = EncodingKey::from_ed_der(key_pair.as_ref());
let header = Header::new(jsonwebtoken::Algorithm::EdDSA);
encode(&header, claims, &encoding_key)
}
```
**3. Provider Discovery:**
```rust
#[derive(Deserialize)]
pub struct OidcDiscovery {
pub issuer: String,
pub authorization_endpoint: String,
pub token_endpoint: String,
pub userinfo_endpoint: String,
pub jwks_uri: String,
pub supported_scopes: Vec<String>,
pub response_types_supported: Vec<String>,
}
pub async fn discover_provider(issuer_url: &str) -> Result<OidcDiscovery, Error> {
let discovery_url = format!("{}/.well-known/openid-configuration", issuer_url);
let response: OidcDiscovery = reqwest::get(&discovery_url).await?.json().await?;
Ok(response)
}
```
**4. Key Management:**
```rust
use ring::{signature, rand};
pub struct KeyManager {
signing_key: signature::Ed25519KeyPair,
verification_keys: HashMap<String, VerifyingKey>,
}
impl KeyManager {
pub fn new() -> Result<Self, Error> {
let signing_key = signature::Ed25519KeyPair::generate_pkcs8(
&rand::SystemRandom::new()
)?;
Ok(Self {
signing_key,
verification_keys: HashMap::new(),
})
}
}
```
**Development Timeline:**
- **Week 1-2**: Protocol research and design
- **Week 3-6**: Core OIDC flow implementation
- **Week 7-10**: Provider integrations (Google, Azure, etc.)
- **Week 11-14**: Security hardening and testing
- **Week 15-16**: Documentation and integration
- **Week 17-20**: Security audit and validation
**Total Effort**: 🕒 **4-5 months full-time development**
---
## 🏆 Recommendations by Use Case
### **For Maximum Security (Zero RSA)**
**Recommended Stack:**
```toml
[dependencies]
auth-framework = { version = "0.3.0", default-features = false, features = [
"postgres-storage", # Use PostgreSQL instead
"redis-cache",
"mfa",
"rate-limiting"
] }
```
**Trade-offs:**
- ✅ Complete RSA elimination
- ✅ PostgreSQL is enterprise-grade
- ❌ Requires PostgreSQL instead of MySQL
- ❌ No OIDC (implement OAuth 2.0 directly)
### **For MySQL + Security Focus**
**Recommended Approach: Custom mysql_async Integration**
```toml
[dependencies]
mysql_async = "0.34"
# Custom OIDC with secure crypto
ring = "0.17"
jsonwebtoken = "9.3"
reqwest = { version = "0.12", features = ["json"] }
```
**Implementation Strategy:**
1. **Phase 1** (2-3 weeks): Replace SQLx with mysql_async
2. **Phase 2** (4-6 weeks): Implement minimal OIDC with Ed25519/ECDSA
3. **Phase 3** (2-3 weeks): Testing and security validation
**Trade-offs:**
- ✅ Eliminates RSA vulnerability completely
- ✅ High-performance MySQL-specific driver
- ❌ Significant development effort (2-3 months)
- ❌ Custom code maintenance burden
### **For Rapid Development (Accept Controlled Risk)**
**Recommended Approach: Current Stack with Risk Mitigation**
```toml
[dependencies]
auth-framework = { version = "0.3.0", features = ["mysql-storage", "openid-connect"] }
```
**Risk Mitigation:**
```rust
// Add timing obfuscation for OIDC operations
use std::time::{Duration, Instant};
use tokio::time::sleep;
pub async fn time_constant_oidc_operation<T>(
operation: impl Future<Output = Result<T, Error>>
) -> Result<T, Error> {
let start = Instant::now();
let result = operation.await;
// Ensure minimum processing time to mask timing differences
let min_duration = Duration::from_millis(100);
let elapsed = start.elapsed();
if elapsed < min_duration {
sleep(min_duration - elapsed).await;
}
result
}
```
**Trade-offs:**
- ✅ Fastest time to market
- ✅ Full feature set immediately available
- ⚠️ Theoretical RSA vulnerability (very low practical risk)
- ✅ Implement timing mitigations
---
## 🔒 Security Considerations
### **Custom Implementation Security Checklist**
If choosing custom OIDC implementation:
**Cryptographic Security:**
- [ ] Use Ed25519 or ECDSA-P256 (no RSA)
- [ ] Implement constant-time comparisons
- [ ] Use secure random number generation
- [ ] Implement proper key rotation
- [ ] Use secure key storage (HSM in production)
**Protocol Security:**
- [ ] Validate all JWT claims (iss, aud, exp, nbf)
- [ ] Implement proper CSRF protection
- [ ] Use PKCE for all flows
- [ ] Validate redirect URIs strictly
- [ ] Implement rate limiting on token endpoints
- [ ] Use secure session management
**Implementation Security:**
- [ ] Constant-time string comparisons
- [ ] Proper input validation and sanitization
- [ ] Secure error handling (no information leakage)
- [ ] Audit logging for all security events
- [ ] Regular security testing and penetration testing
---
## 💰 Cost-Benefit Analysis
### **Development Costs**
| **Current (Accept Risk)** | 0 hours | 20 hours | Very Low |
| **mysql_async + JWT validation** | 160 hours | 40 hours | Very Low |
| **Custom OIDC Implementation** | 800 hours | 120 hours | Low (if done correctly) |
| **PostgreSQL Migration** | 40 hours | 20 hours | None |
### **Long-term Considerations**
**Current Libraries (SQLx + OpenIDConnect):**
- ✅ Continuous security updates from community
- ✅ New features and improvements
- ⚠️ Dependent on upstream vulnerability fixes
**Custom Implementation:**
- ❌ All security updates are your responsibility
- ❌ Must stay current with OIDC spec changes
- ✅ Complete control over security posture
- ✅ No external vulnerability dependencies
---
## 🎯 Final Recommendation
### **For Most Organizations: PostgreSQL Migration**
```toml
[dependencies]
auth-framework = { version = "0.3.0", features = [
"postgres-storage", # Eliminates RSA completely
"redis-cache",
"mfa",
"rate-limiting"
] }
```
**Rationale:**
- ✅ **Zero RSA vulnerability**
- ✅ **Minimal development effort** (2-3 days migration)
- ✅ **PostgreSQL is enterprise-grade** (often superior to MySQL)
- ✅ **Maintains all authentication features**
- ✅ **Long-term security and maintainability**
### **For MySQL-Required Environments: Risk Acceptance**
**Current stack with timing mitigations is production-acceptable** due to:
1. RSA operations not directly exposed to attackers
2. Timing attacks require impractical precision and sample collection
3. Can implement timing obfuscation mitigations
4. Faster time to market with full feature set
### **For Custom Implementation Enthusiasts**
Only pursue custom OIDC if you have:
- ✅ **6+ months development timeline**
- ✅ **Dedicated security expertise**
- ✅ **Ongoing maintenance capacity**
- ✅ **Comprehensive testing resources**
- ✅ **Security audit budget**
---
**The vulnerability exists, but practical exploitation barriers make the current stack acceptable for most production environments while PostgreSQL migration provides the best security-effort trade-off.**
---
*AuthFramework v0.3.0 remains production-ready with any of these approaches.*
