Rust API Authentication, Authorization and Security: Passwords, Tokens, RBAC and Rate Limits

Rust Learning Path — Chapter 25. Security is not a single middleware. A production API needs strong credential handling, authentication, authorization, validation, safe secret storage, abuse controls and observability. This chapter shows how those concerns fit into a Rust backend architecture.

1. Authentication vs authorization#

2. Never store plaintext passwords#

Store a slow password hash produced by a password-hashing algorithm such as Argon2id. Each password should use a unique salt handled by the library.

Do not invent your own cryptographic format.

3. Sessions vs bearer tokens#

Browser applications often work well with secure server-side sessions and cookies. APIs and distributed systems may use signed access tokens. Choose based on threat model and architecture, not fashion.

4. Secure cookies#

For browser sessions, use Secure, HttpOnly and an appropriate SameSite policy. Rotate session identifiers after authentication and invalidate sessions during logout or security events.

5. Token validation#

If using JWT or another signed token format, validate at least the signature, expiration, expected issuer and audience, and only the algorithms your application explicitly supports.

6. Keep access tokens short lived#

Short-lived access credentials limit exposure. If refresh tokens are used, treat them as high-value secrets and support revocation/rotation according to your architecture.

7. Authorization with roles and permissions#

Keep authorization checks close to business operations, not only at the UI layer.

8. Tenant-aware authorization#

In multi-tenant software, checking permission is not enough. Every data access must also enforce the tenant/organization boundary. Never trust a tenant ID from a request without validating the caller's membership.

9. Input validation#

• Maximum string lengths
• Allowed formats
• Numeric ranges
• Pagination limits
• File size/type restrictions
• State-transition/business rules

Deserialize first, then validate semantics. Do not pass untrusted values directly into file paths, commands or dynamic SQL.

10. SQL injection prevention#

Use parameterized database queries:

11. Rate limiting#

Rate limits are especially important around login, password reset, signup, expensive searches and public APIs. Use keys appropriate to the endpoint: account, IP, API key or a combination.

12. CORS#

CORS is a browser security mechanism, not an authentication mechanism. Allow only the origins, methods and headers your frontend requires; avoid permissive credentialed configurations.

13. Security headers#

Depending on the application, consider headers such as Content-Security-Policy, X-Content-Type-Options and an appropriate Referrer-Policy. TLS should be enforced at the edge/reverse proxy.

14. Secrets management#

Do not hard-code database passwords, signing keys or API credentials in source code. Inject secrets at runtime from environment-specific secure storage and make rotation possible.

15. Error responses#

Return useful but non-sensitive client messages. Do not expose SQL text, stack traces, filesystem paths or cryptographic details in API responses.

16. Audit logging#

Record important security events such as login success/failure, password changes, role changes, recovery actions, privileged access and destructive operations. Audit logs should identify actor, action, target, timestamp and request context.

17. File upload safety#

• Limit size.
• Validate content rather than trusting extensions.
• Generate server-side object names.
• Store outside executable web roots.
• Scan files when risk warrants it.

18. Dependency and supply-chain security#

Keep Rust dependencies reviewed and updated, minimize optional features, protect CI credentials and treat build scripts/procedural macros as executable code in your trust model.

19. Security middleware flow#

20. Mini lab#

Add authentication to the Notes API: hash passwords, implement login, protect write endpoints, add reader/editor roles, enforce note ownership, add a login rate limit and write audit events for authentication and deletion.

Key takeaways#

Security is layered. Use proven cryptographic libraries, validate every trust boundary, enforce authorization in backend business logic, keep secrets out of code and make security events observable.