Implementing Security Patterns
1. Service-to-Service Authentication Pattern
| Mechanism | Detail |
|---|
| mTLS | Both sides present certs; mutual auth |
| JWT (with kid) | Signed token; verifiable offline |
| SPIFFE / SPIRE | Workload identity standard |
| API Keys | Simpler; rotate often; not for high security |
2. Token-Based Authentication Pattern
| Token Type | Detail |
|---|
| JWT | Self-contained; signed; can carry claims |
| Opaque (reference) | Random ID; introspect against issuer |
| PASETO | Modern alternative to JWT (no algorithm confusion) |
| Refresh Token | Long-lived; exchanges for new access token |
Example: JWT Bearer
curl -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..." https://api.shop.com/orders
3. OAuth2 Pattern
| Grant Type | Use |
|---|
| Authorization Code + PKCE | Web/mobile/SPA — recommended for users |
| Client Credentials | Service-to-service |
| Device Code | TVs / CLI tools |
| Refresh Token | Renew access without re-login |
| Resource Owner Password | DEPRECATED |
| Implicit | DEPRECATED |
4. API Key Pattern
| Practice | Detail |
|---|
| Transport | Header (X-API-Key) over HTTPS only |
| Storage | Hash at rest (bcrypt/argon2) |
| Rotation | Support N active keys for zero-downtime rotation |
| Scoping | Per-environment, per-permission set |
| Revocation | Immediate; cache TTL ≤ minute |
5. Mutual TLS Pattern
| Aspect | Detail |
|---|
| Mechanism | Client + server present X.509 certs |
| Trust | Internal CA issues short-lived certs |
| Rotation | Auto via cert-manager / Istio |
| Identity | Subject/SAN = service identity |
6. Zero Trust Security Pattern
| Principle | Detail |
|---|
| Never Trust, Always Verify | No implicit trust by network location |
| Verify Explicitly | Authn/z on every call |
| Least Privilege | Minimum permissions per identity |
| Assume Breach | Segment, monitor, encrypt everywhere |
| Continuous Validation | Risk-based re-auth, device posture |
7. Defense in Depth Pattern
| Layer | Control |
|---|
| Edge | WAF, DDoS, rate limit, TLS |
| Network | VPC, security groups, NetworkPolicy, mTLS |
| Service | Authn, authz, input validation |
| Data | Encryption at rest, field-level encryption, KMS |
| Runtime | Container hardening, RASP |
| Monitoring | SIEM, anomaly detection, audit logs |
8. Role-Based Access Control Pattern
| Element | Detail |
|---|
| Subject | User / service |
| Role | Named bundle of permissions (admin, viewer) |
| Permission | Action on resource (orders:read) |
| Pros | Simple, manageable for small permission sets |
| Cons | Role explosion at scale (RBAC sprawl) |
9. Attribute-Based Access Control Pattern
| Element | Detail |
|---|
| Policy | Rules over attributes (subject, resource, action, context) |
| Engine | OPA/Rego, Cedar, AWS IAM conditions |
| Pros | Fine-grained; expressive; scales |
| Cons | Harder to reason; performance considerations |
Example: OPA Rego Policy
package authz
default allow = false
allow {
input.action == "read"
input.user.tenantId == input.resource.tenantId
input.user.role in {"viewer", "editor", "admin"}
}
10. Secrets Management Pattern
| Practice | Detail |
|---|
| Centralized Vault | HashiCorp Vault, AWS Secrets Manager, Azure Key Vault |
| Dynamic Secrets | Issue per-request, short-lived (DB credentials) |
| Auto-Rotation | Periodic; automated |
| Encryption in Transit/Rest | Always |
| Audit | Who accessed what, when |
| Never | Hardcode in code, env vars in YAML, git history |
Warning: Treat any secret committed to git as compromised — rotate immediately, even after deletion.