Skip to main content

​
Current Authentication Status

No Authentication Required: The Iris API currently operates without authentication. All endpoints are publicly accessible without API keys, tokens, or other credentials.
This open design prioritizes simplicity and ease of integration during development and testing phases. However, it comes with important security implications for production deployments.

​
Open API Design

The current implementation allows unrestricted access to all endpoints: 
curl -X POST http://localhost:8080/compare \
  -H "Content-Type: application/json" \
  -d '{"target_url": "...", "people": [...]}'
No headers, tokens, or credentials are required to make requests.

​
Benefits of Open Access

Rapid Integration

Start using the API immediately without authentication setup or key management.

Simplified Testing

Test endpoints freely during development without token rotation or authentication flows.

Low Barrier to Entry

Minimal configuration required for proof-of-concept implementations.

No Key Management

Avoid the complexity of storing, rotating, or securing API keys.

​
Security Considerations

The absence of authentication means anyone who can reach your API endpoint can:
  • Submit face comparison requests
  • Consume computational resources
  • Access the /stats endpoint to view usage metrics
  • Potentially abuse the service

​
Current Protection Mechanisms

While authentication is absent, the API includes basic protection:

​
Rate Limiting (IP-Based)

The API implements rate limiting based on client IP addresses:
  • Rate: 5 requests per second per IP
  • Burst: Up to 10 requests in a burst
  • Scope: Applied to all endpoints (including /compare, /stats, and /health)
  • Response: HTTP 429 (Too Many Requests) when exceeded
// From main.rs:127-129
let quota = Quota::per_second(NonZeroU32::new(5).unwrap())
    .allow_burst(NonZeroU32::new(10).unwrap());
Rate limiting provides basic abuse prevention but is not a substitute for proper authentication in production environments.

​
CORS Configuration

The API allows cross-origin requests from any origin: 
// From main.rs:138-141
let cors = CorsLayer::new()
    .allow_origin(Any)
    .allow_methods([Method::POST, Method::GET])
    .allow_headers([header::CONTENT_TYPE]);
This permissive CORS policy enables browser-based integrations but increases the attack surface.

​
Production Recommendations

Do NOT deploy this API to production without implementing authentication. The open design is suitable only for:
  • Local development environments
  • Internal networks with strict access controls
  • Proof-of-concept demonstrations
  • Testing and evaluation
For production deployments, implement one of these authentication strategies:
Best for: Service-to-service communication, internal tools
  • Generate unique API keys for each client
  • Validate keys in middleware before request processing
  • Include keys in Authorization or custom headers
  • Implement key rotation policies
// Example middleware implementation
async fn auth_middleware(
    headers: HeaderMap,
    request: Request,
    next: Next,
) -> Response {
    if let Some(key) = headers.get("X-API-Key") {
        if validate_api_key(key) {
            return next.run(request).await;
        }
    }
    StatusCode::UNAUTHORIZED.into_response()
}
Best for: User-facing applications, third-party integrations
  • Implement JWT token validation
  • Support standard OAuth 2.0 flows
  • Enable fine-grained permissions and scopes
  • Integrate with identity providers (Auth0, Keycloak, etc.)
use jsonwebtoken::{decode, Validation};

async fn jwt_middleware(
    headers: HeaderMap,
    request: Request,
    next: Next,
) -> Response {
    if let Some(auth) = headers.get("Authorization") {
        if let Ok(token) = extract_bearer_token(auth) {
            if let Ok(claims) = decode::<Claims>(&token, &key, &Validation::default()) {
                return next.run(request).await;
            }
        }
    }
    StatusCode::UNAUTHORIZED.into_response()
}
Best for: High-security environments, zero-trust architectures
  • Require client certificates for all connections
  • Validate certificates at the TLS layer
  • Strongest security but more complex setup
  • Ideal for microservice mesh deployments
Best for: Existing infrastructure with auth layers
  • Deploy API behind nginx, Caddy, or similar
  • Implement authentication at proxy layer
  • Forward authenticated requests to Iris API
  • Leverage existing auth infrastructure
# Example nginx configuration
location /api/ {
    auth_request /auth;
    proxy_pass http://iris-api:8080/;
}

​
Additional Security Measures

Beyond authentication, consider these hardening steps:
1

Enable HTTPS

Use TLS certificates to encrypt all API traffic. Never transmit face data over unencrypted connections.
2

Restrict CORS Origins

Replace allow_origin(Any) with specific allowed origins:
.allow_origin("https://yourdomain.com".parse::<HeaderValue>().unwrap())
3

Implement Request Logging

Log all requests for audit trails and security monitoring.
4

Add Input Validation

Validate image URLs to prevent SSRF attacks and restrict allowed protocols.
5

Use Network Segmentation

Deploy the API in a private subnet, accessible only through authenticated gateways.

​
Network-Level Access Control

If implementing application-level authentication is not immediately feasible, use network-level controls:

​
Firewall Rules

# Allow only specific IPs (example using iptables)
sudo iptables -A INPUT -p tcp --dport 8080 -s 10.0.0.0/8 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8080 -j DROP

​
VPN/Private Network

  • Deploy API within a VPN
  • Require VPN connection for access
  • Use cloud provider’s private networking (AWS VPC, Azure VNet)

​
Container Network Policies

# Kubernetes NetworkPolicy example
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: iris-api-policy
spec:
  podSelector:
    matchLabels:
      app: iris-api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway

​
Migration Path

When adding authentication to an existing deployment:
1

Add Auth Middleware

Implement authentication middleware without enforcing it initially.
2

Enable Soft Enforcement

Log authentication failures but continue processing requests.
3

Notify Clients

Inform API consumers of the upcoming authentication requirement.
4

Hard Enforcement

Enable authentication enforcement and reject unauthenticated requests.
5

Monitor & Adjust

Monitor for authentication failures and assist clients with migration.

​
Frequently Asked Questions

The API is designed as a lightweight, easy-to-deploy face recognition engine. Authentication adds complexity and varies significantly based on deployment context (microservices, standalone apps, etc.). This design allows developers to choose the authentication strategy that best fits their architecture.
Only if deployed in a trusted, isolated network with strict access controls. For internet-facing or multi-tenant deployments, authentication is essential.
Rate limiting provides basic protection but is insufficient for production. Attackers can rotate IPs or use distributed systems to bypass IP-based rate limits.
Your API is vulnerable to:
  • Unauthorized usage and resource consumption
  • Data exfiltration through the comparison endpoint
  • Denial of service attacks
  • Compliance violations (GDPR, CCPA, etc.)
  • Potential legal liability

​
Next Steps

Error Handling

Learn about error responses and troubleshooting

Integration Examples

See complete authentication implementation examples

Build docs developers (and LLMs) love

Get started for freeTalk to us