JWT比基础认证更安全，因其签名+可选加密实现状态无关、可验证、有时效的认证；需用PyJWT生成token，密钥存环境变量，payload精简且设exp/iat，每次校验签名、时效与Header格式，敏感操作加二次验证。
API认证：用JWT替代基础认证更安全
基础认证（Basic Auth）把用户名密码Base64编码后传在Header里，本质无加密，一旦被截获就等于泄露凭证。JWT（JSON Web Token）则通过签名+可选加密，实现状态无关、可验证、有时效的认证机制。
实践建议：
- 使用PyJWT库生成token，密钥（SECRET_KEY）必须足够长且存于环境变量，绝不可硬编码
- payload中只放必要字段（如user_id、role），避免敏感信息；设置exp（过期时间）和iat（签发时间）
- 每次请求校验token签名有效性、是否过期、是否被篡改；拒绝没有Authorization: Bearer 头的请求
- 敏感操作（如删账号、改密码）额外要求二次验证（如短信/邮箱确认），不单靠JWT
接口授权：按角色
+资源粒度控制访问权限
认证通过只代表“你是谁”，授权决定“你能做什么”。简单用@admin_required装饰器不够，需结合角色（Role）、资源（Resource）、操作（Action）三要素动态判断。
推荐做法：
- 在用户登录成功后，将权限列表（如["post:read", "post:write", "user:delete"]）写入JWT的permissions字段，服务端解析后缓存，避免每次查DB
- 定义统一的权限检查函数，例如has_permission(user_perms, resource='order', action='update')，内部匹配前缀或精确规则
- 对高危资源（如/api/v1/users//reset-password）启用白名单机制，仅允许特定IP段或客户端证书访问
- 定期审计权限分配，禁用离职人员token，并提供管理员一键回收某用户所有活跃token的能力
数据传输加密：HTTPS是底线，敏感字段再加一层保护
HTTPS解决传输层窃听与篡改，但无法防止服务端日志泄露、数据库被拖库等场景。对身份证号、手机号、银行卡等强敏感字段，需在应用层做额外加密。
实操要点：
- 使用cryptography库的Fernet（对称加密）或RSA（非对称），避免自己实现加解密逻辑
- 敏感字段入库前加密，查询后解密返回；注意加密后字段长度变化，数据库字段类型要预留足够空间（如VARCHAR(255)→TEXT）
- 禁止在URL、Query参数、Cookie、日志中明文记录敏感数据；使用logging.Filter过滤含id_card、phone等关键字的日志行
- 若调用第三方API需传敏感数据，优先使用其提供的令牌化（Tokenization）或字段级加密（FPE）方案，而非自行加密
防滥用与风控：限流+签名+行为审计缺一不可
开放API易成攻击入口，暴力遍历、重放攻击、爬虫刷量都可能绕过认证直接打垮服务。
关键防护措施：
- 用slowapi或fastapi-limiter实现多级限流：全局QPS、用户级每分钟请求数、IP级并发连接数
- 对关键接口（如登录、支付回调）启用请求签名：客户端用私钥对timestamp+body+path生成签名，服务端用公钥验签，并拒绝15秒外的请求
- 记录完整访问日志（含IP、User-Agent、响应状态码、耗时、JWT中的user_id），用ELK或Prometheus+Grafana做异常检测（如单IP 5分钟内401错误超20次）
- 对高频失败请求自动触发人机验证（如滑块），或临时加入延迟队列，避免自动化工具快速试探
+资源粒度控制访问权限