Completed Issues Archive#

This file contains security issues and improvements that have been successfully implemented in the bskyoauth library. These items have been moved from TODO.md to reduce noise and keep the active TODO list focused on pending work.

All completed issues are documented in CHANGELOG.md with version numbers and implementation details.

COMPLETED ISSUES#

18. Environment Configuration ✅ COMPLETED (v1.3.1)#

Status: FIXED - See VERSION.md for details

Issue: Limited configuration options via environment variables.

Implementation:

✅ Added 4 configurable environment variables
- SESSION_TIMEOUT_DAYS - Cookie lifetime configuration (default: 30 days)
- RATE_LIMIT_AUTH - Auth endpoint rate limits (default: 5 req/s, burst 10)
- RATE_LIMIT_API - API endpoint rate limits (default: 10 req/s, burst 20)
- SERVER_PORT - HTTP server port (default: 8181)
✅ Helper functions for environment variable parsing
- getEnvInt() - Parse integers with validation and defaults
- getRateLimitConfig() - Parse "requests/sec,burst" format
- validateConfig() - Range validation with warnings
✅ Configuration validation features
- Automatic validation on startup
- Warning logs for unusual but valid values
- Graceful fallback to defaults for invalid values
- Clear error messages with expected format
✅ Comprehensive documentation
- Environment variable reference with defaults and examples
- Configuration examples for dev, staging, production, high-traffic
- Deployment examples (Docker, Docker Compose, Kubernetes)
- Rate limiting guidelines by scenario
- Session timeout security recommendations

Scope Decision:

Minimal approach: Only 4 most critical production configuration needs
NOT included (kept hardcoded with good defaults):
- HTTP client timeout (30s is industry standard)
- Server read/write/idle timeouts (current values are best practice)
- Cookie security flags (auto-detected from HTTPS, should not be overridden)
- Logging level (already auto-configured based on environment)

Testing:

✅ Default values work without any environment variables
✅ Custom values applied correctly
✅ Invalid values fall back to defaults with warnings
✅ Unusual values trigger warnings but still apply
✅ Server port configuration tested
✅ Rate limit configuration tested (format: "req/sec,burst")
✅ Session timeout calculation tested (days to seconds conversion)

Features:

12-Factor App: Environment-based configuration
Container-Friendly: Works with Docker, K8s, orchestration
Secure by Default: All optional, sensible defaults maintained
Production-Ready: Per-environment configuration without code changes
User-Friendly: Clear validation messages, graceful degradation

Architecture:

Example application only (no core library changes)
Zero breaking changes
Backward compatible (all env vars optional)
Follows Go conventions (strconv, validation, error handling)

Impact:

Flexibility: Production deployments can tune rate limits and timeouts
Simplicity: Only 4 variables (minimal configuration burden)
Safety: Validation prevents misconfiguration
Documentation: Clear guidance for all deployment scenarios

Files Modified:

examples/web-demo/main.go - Added env parsing and validation (~70 lines)
README.md - Added environment variable documentation (~185 lines)

Test Results:

✅ Defaults: Port 8181, session 30 days, auth 5/10, API 10/20
✅ Custom: All values configurable and applied correctly
✅ Invalid: Falls back to defaults, logs warnings
✅ Unusual: Applies value, logs configuration warning
✅ No regressions: Existing functionality unchanged

17. Audit Trail Support ✅ COMPLETED (v1.3.0)#

Status: FIXED - See CHANGELOG.md and VERSION.md for details

Issue: No audit log for sensitive operations.

Implementation:

✅ Core audit infrastructure (audit.go)
- AuditEvent struct with standardized fields (timestamp, event_type, actor, action, resource, result, error, metadata, request_id, session_id)
- AuditLogger interface for flexible implementations
- NoOpAuditLogger as safe default (opt-in design)
- 15+ standardized event type constants
- Package-level functions: SetAuditLogger(), GetAuditLogger(), LogAuditEvent()
- Automatic context enrichment (timestamps, request IDs, session IDs)
✅ Built-in implementations (audit_file.go)
- FileAuditLogger - Simple append-only file logging
- RotatingFileAuditLogger - Daily log rotation at midnight UTC
- Thread-safe concurrent writes with mutex protection
- Restrictive file permissions (0600) for tamper resistance
- Automatic directory creation
✅ Comprehensive integration across all sensitive operations:
- OAuth flow (oauth.go):
  - auth.start - Flow initiation (success/failure)
  - auth.callback - Callback received
  - auth.success / auth.failure - Flow completion
  - security.issuer_mismatch - Code injection attempt (critical)
  - security.invalid_state - CSRF attack attempt
- Token refresh (oauth.go):
  - session.refresh - Token refresh (success/failure)
- API operations (client.go):
  - api.post.create - Post creation
  - api.record.create - Custom record creation
  - api.record.read - Record retrieval
  - api.record.delete - Record deletion
✅ Testing (audit_test.go)
- 10 comprehensive test functions
- Tests for all loggers (NoOp, File, Rotating)
- Thread-safety testing under concurrent load
- Event structure validation
- Context enrichment verification
- Mock logger for testing custom implementations
- All tests pass with -race detection
✅ Documentation (README.md)
- New "Audit Trail" section (380+ lines)
- Quick start guide
- Complete event type reference
- JSON log format specification
- Built-in logger documentation (FileAuditLogger, RotatingFileAuditLogger)
- Custom logger examples (PostgreSQL, Splunk/SIEM)
- Manual audit logging for custom events
- Context enrichment guide
- Compliance best practices (retention, integrity, access control, monitoring)
- Performance considerations (buffering, rotation, sampling, compression)
- Security event examples with JSON output

Features:

Structured Logging: JSON-formatted events with standardized schema
Automatic Enrichment: Context-aware request/session ID injection
Thread-Safe: All loggers safe for concurrent use
Flexible: Interface-based design supports any backend (file, database, SIEM)
Opt-In: No-op default logger ensures zero overhead unless explicitly enabled
Compliance-Ready: Tamper-evident logs for SOX, PCI-DSS, HIPAA, etc.
Production-Ready: Daily rotation, restrictive permissions, append-only files

Architecture:

Clean separation: audit.go (core), audit_file.go (implementations), audit_test.go (tests)
Integration points: oauth.go (auth flow), client.go (API operations)
Package-level singleton pattern with SetAuditLogger() for global configuration
Context-aware enrichment using Go context values

Impact:

Security: Complete audit trail of authentication, authorization, and data operations
Compliance: Meets requirements for SOX, PCI-DSS, HIPAA, GDPR
Forensics: Tamper-evident log trail for security incident investigation
Monitoring: Structured events enable real-time alerting on security events
Zero Breaking Changes: Fully backward compatible (minor version bump)

Files Added:

audit.go - Core audit infrastructure (159 lines)
audit_file.go - File-based audit loggers (177 lines)
audit_test.go - Comprehensive test suite (532 lines)

Files Modified:

oauth.go - Integrated audit logging into auth flow
client.go - Integrated audit logging into API operations
README.md - Added 380+ lines of audit trail documentation

Test Results:

All 10 audit tests pass
All 22 existing tests pass (no regressions)
Race detection clean
100% backward compatibility maintained

16. DPoP Key Storage Considerations ✅ COMPLETED (v1.2.1)#

Status: RESOLVED via comprehensive documentation - See README.md

Issue: DPoP private keys stored in memory only. Lost on application restart.

Resolution: Resolved through enhanced documentation rather than code implementation. Ephemeral DPoP keys are intentional and align with OAuth 2.0 security best practices.

Documentation Added (v1.2.1):

✅ New README section: "DPoP Key Persistence and Security Considerations"
✅ Security trade-offs table (Ephemeral vs Persisted vs Hybrid)
✅ Three implementation options with complete code examples:
1. Option 1: Ephemeral Keys (Default - Recommended for most apps)
2. Option 2: Hybrid Approach (Recommended for production - ephemeral keys + token refresh)
3. Option 3: Encrypted Persistence (Advanced - for mobile/desktop apps)
✅ Complete SecureRedisSessionStore implementation with AES-256-GCM encryption
✅ Security requirements checklist (encryption, key management, storage, monitoring)
✅ Key rotation guidance
✅ Summary recommendations by scenario (web/API/mobile/desktop)
✅ Warning added to simple Redis example about plaintext key storage

Why Documentation Over Implementation:

Security Decision: Persisting keys is a security trade-off users must consciously make
Interface Already Exists: SessionStore allows any persistence strategy
Use Case Varies: Different applications have different security/UX requirements
Encryption Key Management: Library can't safely manage encryption keys for users
Current Design is Correct: Ephemeral keys are OAuth 2.0 best practice

Key Benefits:

Ephemeral keys (default): Maximum security, zero storage risk
Token refresh: Extends sessions without persisting keys
Encrypted option: Available for apps that truly need persistence

Impact: Users now have clear guidance on DPoP key lifecycle, security trade-offs, and implementation options for their specific use case. Default behavior remains secure-by-default with ephemeral keys.

15. Add Security Testing ✅ COMPLETED (v1.2.0)#

Status: FIXED - See CHANGELOG.md and VERSION.md for details

Issue: No security-focused tests.

Implementation:

✅ Added comprehensive CSRF protection tests (8 tests in security_csrf_test.go)
✅ Added session security tests (6 tests in security_session_test.go)
✅ Added rate limiting evasion tests (3 tests in security_ratelimit_test.go)
✅ Added fuzzing for input validation (5 fuzz tests in validation_fuzz_test.go)
⚠️ Penetration testing remains a recommendation for production deployments

Test Coverage:

State parameter CSRF protection and replay attack prevention
Issuer validation for authorization code injection prevention
Session hijacking and fixation prevention
Session expiration enforcement (cookie, store, cleanup)
Cookie security flags (HttpOnly, Secure, SameSite)
Rate limit evasion via header manipulation
IPv6 rate limiting and distributed attacks
Fuzzing for handles, post text, NSIDs, and record structures

Files Added:

security_csrf_test.go - 8 CSRF protection tests
security_session_test.go - 6 session security tests
security_ratelimit_test.go - 3 rate limiting tests
validation_fuzz_test.go - 5 fuzzing tests

Test Results:

All 22 tests pass with -race detection
Zero breaking changes (tests only)
Thread-safety verified under concurrent access
Continuous fuzzing for edge case discovery

Impact: Enhanced security confidence through comprehensive attack simulation and edge case testing. All tests simulate real-world attack scenarios.

File: examples/web-demo/main.go:137-157, examples/web-demo/main.go:270-297

Status: FIXED - See CHANGELOG.md for details

Issue: Session cookies lack Secure flag and session expiration controls.

Implementation:

✅ Added Secure flag with automatic HTTPS detection
- Checks BASE_URL environment variable
- Enables Secure flag when https:// is detected
- Safe for localhost development (HTTP allowed)
✅ Added MaxAge: 86400 (24 hours) for session expiration
✅ Updated callback success handler with enhanced cookie security
✅ Updated logout handler to match cookie attributes for proper deletion
✅ Maintained HttpOnly and SameSite protections
✅ Environment-aware: automatically adapts to deployment context

Cookie Configuration:

http.SetCookie(w, &http.Cookie{
    Name:     "session_id",
    Value:    sessionID,
    Path:     "/",
    HttpOnly: true,                  // Prevents JavaScript access
    Secure:   isSecure,               // HTTPS only in production
    SameSite: http.SameSiteLaxMode,   // CSRF protection
    MaxAge:   86400,                  // 24 hours
})

Impact: Prevents cookie interception via HTTPS enforcement and limits session hijacking with time-bound expiration.

2. In-Memory Session Store Lacks Expiration ✅ COMPLETED#

File: types.go:61-185

Status: FIXED - See CHANGELOG.md for details

Issue: MemorySessionStore had no automatic cleanup or TTL mechanism. Sessions persisted indefinitely, causing:

Memory leaks in long-running applications
Increased attack surface for stolen sessions
No automatic session invalidation

Implementation:

✅ Added 30-day TTL for sessions (configurable, matches cookie MaxAge)
✅ Implemented automatic cleanup goroutine (runs every 5 minutes)
✅ Added expiration validation on retrieval (defense-in-depth)
✅ Created sessionEntry wrapper with expiresAt timestamp
✅ Added NewMemorySessionStoreWithTTL() for custom TTL configuration
✅ Added Stop() method for graceful shutdown
✅ Comprehensive test coverage added (7 new tests)
✅ Thread-safe with proper RWMutex usage
✅ Documentation added to README.md with examples

Impact: Memory leaks prevented, session hijacking window limited to 30 days (configurable), proper resource management in long-running applications.

3. OAuth State Store Memory Leak ✅ COMPLETED#

File: oauth.go:36-138

Status: FIXED - See CHANGELOG.md for details

Issue: globalStateStore never expires entries. If authorization flow is abandoned:

State tokens persist forever
DPoP private keys remain in memory
Potential memory exhaustion

Implementation:

✅ Added 10-minute TTL for OAuth state entries (configurable)
✅ Implemented automatic cleanup goroutine (runs every 1 minute)
✅ Added expiration validation on retrieval (defense-in-depth)
✅ Graceful shutdown support for cleanup goroutine
✅ Comprehensive test coverage added
✅ Thread-safe with proper mutex usage

Impact: Memory leaks prevented, DoS vector eliminated, improved resource management.

4. Missing HTTPS Enforcement Documentation ✅ COMPLETED#

File: README.md, examples/web-demo/main.go

Status: FIXED - See CHANGELOG.md for details

Issue: Documentation doesn't emphasize HTTPS requirement for production. OAuth flows over HTTP expose:

Authorization codes
State parameters
Session cookies

Implementation:

✅ Added prominent ⚠️ HTTPS warning at top of Security section
✅ Created comprehensive "Production Deployment Best Practices" section
✅ Added reverse proxy configuration examples (nginx, Caddy)
✅ Documented cookie security settings with code examples
✅ Added production security checklist (12 items)
✅ Web-demo example now validates BASE_URL and warns when HTTP is used
✅ Web-demo shows success message when HTTPS is configured
✅ Documented session storage, rate limiting, and additional security measures

Impact: Prevents credential exposure in transit, provides clear guidance for secure deployments.

5. Missing CSRF Token Validation Enhancement ✅ COMPLETED#

File: oauth.go:246-254

Status: FIXED - See CHANGELOG.md for details

Issue: While OAuth state parameter provides CSRF protection, the callback handler doesn't validate issuer (iss) parameter matches expected domain.

Implementation:

✅ Added ExpectedIssuer field to internalOAuthState struct
✅ Expected issuer stored during StartAuthFlow based on resolved handle
✅ Issuer validation performed in CompleteAuthFlow before token exchange
✅ New ErrIssuerMismatch error type for attack detection
✅ Security event logging to stderr for monitoring (includes expected vs actual)
✅ Validation occurs before any network requests to issuer
✅ Test coverage added for issuer storage and retrieval

Impact: Prevents authorization code injection attacks, enables security monitoring.

6. Error Information Disclosure ✅ COMPLETED#

Files: oauth.go:202-208, oauth.go:388-393

Status: FIXED - See CHANGELOG.md for details

Issue: Error messages expose internal implementation details:

Auth server metadata request failures exposed HTTP status and response body
Token exchange failures exposed HTTP status and response body
Could leak internal server details, error messages, or system information to attackers

Implementation:

✅ Added internal logging to stderr for detailed error information
✅ Generic error messages returned to users (only status code included)
✅ Auth metadata errors: Log full details, return generic message
✅ Token exchange errors: Log full details, return generic message
✅ Prefix logging with "AUTH_ERROR:" and "TOKEN_ERROR:" for easy monitoring
✅ Maintains error wrapping for proper error handling
✅ No breaking changes - error types remain consistent

Impact: Prevents information leakage while maintaining debugging capability through logs.

8. Missing Rate Limiting ✅ COMPLETED#

Files: ratelimit.go, examples/web-demo/main.go:31-47

Status: FIXED - See CHANGELOG.md for details

Issue: No rate limiting on:

Login attempts - vulnerable to brute force
OAuth callback endpoint - vulnerable to enumeration
API operations - vulnerable to DoS

Implementation:

✅ Created RateLimiter type using golang.org/x/time/rate
✅ Token bucket algorithm with configurable rate and burst limits
✅ IP-based rate limiting per endpoint
✅ Middleware pattern for easy integration
✅ X-Forwarded-For header support for proxied requests
✅ Automatic cleanup of idle limiters (prevents memory leaks)
✅ Applied to web-demo example:
- Auth endpoints (login, callback): 5 req/s, burst 10
- API endpoints (post, create, delete): 10 req/s, burst 20
✅ Returns HTTP 429 (Too Many Requests) when limit exceeded
✅ Periodic cleanup every 5 minutes

Impact: Prevents brute force, enumeration, and DoS attacks on sensitive endpoints.

9. Missing Input Validation and Sanitization ✅ COMPLETED#

File: validation.go, client.go:103-104, client.go:167-174, examples/web-demo/main.go:185-188

Status: FIXED - See CHANGELOG.md for details

Issue: Limited validation on user inputs:

Handle validation is minimal
Post text has no length limits
Custom record data not validated

Implementation:

✅ Created comprehensive validation.go module with centralized validation functions
✅ Added ValidateHandle() to validate handles per AT Protocol spec (max 253 chars, proper format)
✅ Added ValidatePostText() to validate post text (max 300 chars per AT Protocol spec)
✅ Added ValidateTextField() for generic text field validation with configurable limits
✅ Added ValidateRecordFields() for record structure validation
✅ Added ValidateCollectionNSID() for collection name validation
✅ Leverages AT Protocol syntax package from indigo for spec-compliant validation
✅ UTF-8 validation and null byte rejection
✅ Deep nesting prevention (max 10 levels) to prevent memory exhaustion
✅ Comprehensive error types: ErrHandleInvalid, ErrTextTooLong, ErrInvalidUTF8, etc.
✅ Created validation_test.go with 36 comprehensive test cases
✅ Updated LoginHandler to validate handle format before OAuth flow
✅ Updated CreatePost to validate text before API call
✅ Updated CreateRecord to validate collection NSID and record fields
✅ Updated web-demo postHandler to validate post text client-side
✅ Updated web-demo createOngakuHandler to validate text field (1000 char limit)
✅ All validation functions exported for use by library consumers
✅ Comprehensive README documentation with usage examples
✅ Test count increased from 127 to 193 tests (66 new validation tests)

Validation Features:

Handles: Max 253 chars, segments max 63 chars, valid characters (a-z, 0-9, hyphen)
Post Text: Max 300 chars (AT Protocol spec), UTF-8 validated, no null bytes
Custom Records: Configurable limits, datetime validation, nesting prevention
Collection NSIDs: Validated using AT Protocol syntax package

Example Usage:

// Validate handle
if err := bskyoauth.ValidateHandle("alice.bsky.social"); err != nil {
    return err
}

// Validate post text
if err := bskyoauth.ValidatePostText("Hello, world!"); err != nil {
    return err
}

// Validate custom field
if err := bskyoauth.ValidateTextField(text, "description", 500); err != nil {
    return err
}

Impact: Prevents injection attacks, resource exhaustion, and API errors. Provides early validation with clear error messages.

10. Missing Security Headers ✅ COMPLETED#

File: securityheaders.go, securityheaders_test.go, examples/web-demo/main.go

Status: FIXED - See CHANGELOG.md for details

Issue: No security headers middleware in main library:

No Content-Security-Policy
No X-Frame-Options
No X-Content-Type-Options
No Strict-Transport-Security

Implementation:

✅ Created SecurityHeadersMiddleware() in main library (securityheaders.go)
✅ Automatic localhost detection from HTTP request's Host header
✅ Localhost CSP: Relaxed with 'unsafe-inline' and 'unsafe-eval' for development
✅ Production CSP: Strict with no unsafe directives, includes frame-ancestors 'none'
✅ HSTS: Automatically enabled for HTTPS in production (never for localhost)
✅ HTTPS detection via r.TLS or X-Forwarded-Proto header
✅ Zero configuration required - works automatically from HTTP request
✅ Handles reverse proxies, Docker, and cloud platforms automatically
✅ Comprehensive test suite (securityheaders_test.go) with 13 test cases
✅ Applied to web-demo example with single line of code
✅ Documentation added to README.md with usage examples
✅ CHANGELOG.md updated with technical details

Headers Applied:

Content-Security-Policy: Environment-aware (relaxed localhost, strict production)
X-Frame-Options: DENY (prevents clickjacking)
X-Content-Type-Options: nosniff (prevents MIME-sniffing attacks)
Strict-Transport-Security: HTTPS production only (not localhost)
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin

How It Works:

// Simply wrap your handler
mux := http.NewServeMux()
// ... set up handlers ...
handler := bskyoauth.SecurityHeadersMiddleware()(mux)
http.ListenAndServe(":8080", handler)

Localhost Detection:

Checks r.Host for: localhost, 127.0.0.1, [::1], 0.0.0.0
Handles IPv6 addresses with brackets correctly
Strips port numbers for detection

Test Coverage:

Localhost detection tests (IPv4, IPv6, ports)
CSP policy tests (localhost vs production)
HSTS tests (HTTP, HTTPS, localhost)
Header application tests (all headers present)
Handler execution tests (middleware doesn't break handlers)

Impact: All library users get security headers automatically. Localhost-friendly development with production-ready security. Works in any deployment scenario without configuration.

11. Insufficient Logging and Monitoring ✅ COMPLETED#

Files: Multiple locations (oauth.go, session.go, client.go, ratelimit.go, logger.go, logger_test.go)

Status: FIXED - See CHANGELOG.md for details

Issue: Limited security event logging:

No failed login attempt logging
No session lifecycle events
No suspicious activity monitoring

Implementation:

✅ Added comprehensive structured logging using Go's standard log/slog package
✅ Environment-based configuration (Info for localhost, Error for production)
✅ Silent by default (logs to io.Discard unless explicitly configured)
✅ Automatic format selection: Text for development, JSON for production
✅ Context-aware logging with request ID and session ID correlation
✅ Security event logging throughout the codebase:
- OAuth flow: start/completion, token exchange, DPoP nonce retries
- Session management: creation, retrieval, deletion, expiration, cleanup
- API operations: post creation, record operations, failures
- Rate limiting: exceeded limits, cleanup operations
✅ Security events logged at ERROR level:
- Issuer mismatch attacks
- Invalid OAuth states
- Token exchange failures
- No valid session errors
✅ New logger functions:
- SetLogger() - Configure global logger
- NewLoggerFromEnv() - One-line setup with environment detection
- LogLevelFromEnv() - Detect log level from BASE_URL
- NewDefaultLogger() - JSON logger with custom level
- NewTextLogger() - Text logger with custom level
✅ Context helpers for correlation:
- WithRequestID() - Add request ID to context
- WithSessionID() - Add session ID to context
- LoggerFromContext() - Retrieve logger from context
- GenerateRequestID() - Generate unique request ID
✅ Comprehensive test coverage (11 new tests in logger_test.go)
✅ Documentation added to README.md with examples
✅ All tests passing (193 total tests)

Logging Levels:

Debug: Rate limit checks passed, session retrieval details
Info: OAuth flow events, session lifecycle, API operations
Warn: Failed lookups, invalid inputs, rate limit exceeded
Error: Security events, critical failures, authentication errors

Example Usage:

// Automatic environment-based setup
logger := bskyoauth.NewLoggerFromEnv(os.Getenv("BASE_URL"))
bskyoauth.SetLogger(logger)

// Manual configuration
logger := bskyoauth.NewDefaultLogger(slog.LevelError) // JSON, Error level
bskyoauth.SetLogger(logger)

// Context-aware logging
ctx := bskyoauth.WithRequestID(r.Context(), bskyoauth.GenerateRequestID())
ctx = bskyoauth.WithSessionID(ctx, sessionID)
session, err := client.CompleteAuthFlow(ctx, code, state, iss)
// Logs include request_id and session_id fields

Impact: Enables security incident detection and investigation. Provides request correlation through IDs. Environment-aware configuration for development and production. Zero external dependencies using Go standard library.

12. Refresh Token Not Implemented ✅ COMPLETED#

Files: oauth.go, types.go, client.go, token_test.go

Status: FIXED - See CHANGELOG.md for details

Issue: Refresh token is stored but never used. Access tokens will expire requiring full re-authentication.

Implementation:

✅ Added RefreshToken() method to exchange refresh tokens for new access tokens
✅ Added token expiration tracking to Session struct:
- AccessTokenExpiresAt time.Time - When access token expires
- RefreshTokenExpiresAt time.Time - When refresh token expires (optional)
✅ Token expiration automatically parsed from OAuth token responses in CompleteAuthFlow()
✅ Added token expiration helper methods:
- IsAccessTokenExpired(buffer time.Duration) - Check if token expired or will expire soon
- IsRefreshTokenExpired() - Check if refresh token expired
- TimeUntilAccessTokenExpiry() - Get duration until expiration
✅ Added UpdateSession() method to update sessions after refresh
✅ DPoP binding maintained across token refresh (same DPoP key used)
✅ Single-use refresh tokens per AT Protocol spec (old token invalidated after use)
✅ Added refreshTokenRequest() helper with DPoP nonce retry support
✅ Comprehensive logging throughout refresh process:
- Token expiration parsing
- Refresh initiation and completion
- Error conditions (no token, expired token, network errors)
✅ 6 new test cases in token_test.go:
- TestIsAccessTokenExpired (5 sub-cases)
- TestIsRefreshTokenExpired (3 sub-cases)
- TestTimeUntilAccessTokenExpiry (3 sub-cases)
- TestUpdateSession
- TestRefreshToken_NoRefreshToken
- TestRefreshToken_ExpiredRefreshToken
✅ Full documentation in README with examples
✅ Zero breaking changes - all additions backwards compatible

Key Features:

Manual Refresh: Call RefreshToken() when tokens expire
Expiration Checking: Helper methods to check token status
Error Handling: Clear errors for expired/missing tokens
AT Protocol Compliance: Single-use tokens, DPoP binding maintained
Flexible: No expiration data? Methods assume tokens valid

Example Usage:

// Check if token needs refresh
if session.IsAccessTokenExpired(5 * time.Minute) {
    newSession, err := client.RefreshToken(ctx, session)
    if err != nil {
        // Refresh failed - redirect to login
        return redirectToLogin(w, r)
    }

    // Update session in store
    client.UpdateSession(sessionID, newSession)
    session = newSession
}

// Use refreshed session
client.CreatePost(ctx, session, "Hello!")

Impact: Users no longer need to re-authenticate when access tokens expire. Improves user experience and enables shorter-lived access tokens for better security.

13. Add Context Timeout Handling ✅ COMPLETED#

Files: oauth.go, client.go, errors.go, timeout_test.go, errors_test.go

Status: FIXED - See CHANGELOG.md for details

Issue: HTTP requests lacked explicit timeout configurations, potentially causing indefinite hangs.

Implementation:

✅ Added defaultHTTPClient with comprehensive timeout configuration:
- Total request timeout: 30 seconds
- Connection timeout: 10 seconds (TCP handshake)
- TLS handshake timeout: 10 seconds
- Response header timeout: 10 seconds
- Idle connection reuse: 90 seconds
- Connection pooling: Max 100 idle connections, 10 per host
✅ Replaced all http.Get() calls with context-aware http.NewRequestWithContext():
- 3 occurrences in StartAuthFlow(), CompleteAuthFlow(), and RefreshToken()
- All requests now respect context cancellation and timeouts
✅ Updated all http.NewRequest() calls to use context:
- 2 main requests and 2 retry requests in token exchange functions
- Proper error handling for request creation failures
✅ Added SetHTTPClient() and GetHTTPClient() for global HTTP client configuration
✅ Added HTTPClient field to ClientOptions for per-client timeout customization
✅ Created errors.go with IsTimeoutError() helper function:
- Detects context.DeadlineExceeded
- Detects net.Error with Timeout() == true
- Detects os.ErrDeadlineExceeded
- Supports wrapped errors
✅ Added timeout-specific error logging throughout OAuth flow
✅ 10 comprehensive test cases:
- TestHTTPClientTimeout - Verifies HTTP timeout behavior
- TestContextCancellation - Tests context cancellation handling
- TestSetHTTPClient / TestGetHTTPClient - Tests client configuration
- TestClientOptionsWithHTTPClient - Tests per-client configuration
- TestIsTimeoutError_* - 5 tests for timeout error detection
- TestDefaultHTTPClientSettings - Validates default timeout values
✅ Full documentation in README with examples for:
- Custom HTTP client timeouts
- Context-based per-request timeouts
- Testing with custom timeouts
- Timeout error detection
✅ Zero breaking changes - all additions backwards compatible with sensible defaults

Key Features:

Automatic Timeouts: All requests have 30s default timeout
Configurable: Set custom HTTP client globally or per-client
Context-Aware: Respect context cancellation and deadlines
Error Detection: Easy identification of timeout errors
Connection Pooling: Efficient connection reuse

Example Usage:

// Custom timeout for specific client
customClient := &http.Client{Timeout: 10 * time.Second}
client := bskyoauth.NewClientWithOptions(bskyoauth.ClientOptions{
    BaseURL:    "https://myapp.com",
    HTTPClient: customClient,
})

// Context timeout for specific request
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

flowState, err := client.StartAuthFlow(ctx, handle)
if err != nil {
    if bskyoauth.IsTimeoutError(err) {
        log.Println("Request timed out")
    }
}

Impact: Prevents indefinite hangs from unresponsive servers or network issues. Improves reliability and enables better error handling for production deployments.

14. Dependency Security Scanning ✅ COMPLETED#

Files: .github/dependabot.yml, .github/workflows/security.yml

Status: FIXED - See CHANGELOG.md for details

Issue: No automated dependency vulnerability scanning.

Implementation:

✅ Added Dependabot configuration (.github/dependabot.yml):
- Weekly Go module dependency updates (Mondays at 9am Pacific)
- Groups minor and patch updates together to reduce PR noise
- Maximum 5 open PRs to keep review manageable
- Auto-labels PRs with "dependencies" and "go"
- Auto-rebase strategy for conflict resolution
- Commit message prefix: "deps"
✅ Added GitHub Actions security workflow (.github/workflows/security.yml):
- Runs govulncheck for vulnerability scanning
- Executes on push, pull requests, and weekly schedule
- Test suite with race detection (-race flag)
- Coverage reporting to Codecov
- Uses Go version from go.mod for consistency
✅ Scheduled weekly security scans (Mondays at 9am Pacific)
✅ Automatic monitoring of security advisories via Dependabot

Key Features:

Automated Updates: Weekly dependency update PRs
Vulnerability Scanning: govulncheck integration in CI/CD
Smart Grouping: Minor/patch updates grouped to reduce noise
Test Coverage: Full test suite runs on all security checks
Zero Maintenance: Fully automated, no manual intervention needed

Example Workflow:

Dependabot checks for updates every Monday
Creates PR with grouped dependency updates
Security workflow runs automatically
govulncheck scans for vulnerabilities
Tests run with race detection
Review and merge PR if checks pass

Impact: Proactive security monitoring ensures vulnerabilities are detected quickly. Automated updates keep dependencies current with minimal maintenance overhead.

For details on implementation and version numbers, see CHANGELOG.md.

Last updated: 2025-10-29

Completed Issues Archive#