答案：HTTP认证机制

为什么 Basic 认证的 Base64 编码"等同于明文"？用命令行演示如何解码 Basic YWhhbmc6MTIzNA==。

答案：

Base64 只是一种编码方式，不是加密算法。它的设计目的是把二进制数据转换成 ASCII 字符串以便传输，完全没有密钥、没有密码学保护。任何人拿到 Base64 字符串都能瞬间还原原始内容。

在飞翔公司早期，空少（后端实习生）曾在内网系统用 Basic 认证，以为 Authorization: Basic YWhhbmc6MTIzNA== 看起来"像加密了"，结果被凌叔一眼识破——这串字符解码后就是 ahang:1234，用户名密码一览无余。

命令行演示：

# 方法1：Linux/Mac 用 base64 命令解码
echo "YWhhbmc6MTIzNA==" | base64 -d
# 输出：ahang:1234

# 方法2：Python 解码
python3 -c "import base64; print(base64.b64decode('YWhhbmc6MTIzNA==').decode())"
# 输出：ahang:1234

# 方法3：浏览器控制台
# atob('YWhhbmc6MTIzNA==')
# 输出："ahang:1234"

更危险的是，Basic 认证把用户名和密码放在 HTTP 请求头里，如果连接不是 HTTPS，中间人（比如公共 WiFi 上的嗅探工具）可以直接抓包获取：

# 用 tcpdump 或 Wireshark 抓包，过滤 HTTP 请求
tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
# 在明文 HTTP 流量中，Authorization: Basic xxx 完全可见

因此翼王（CTO）明确规定：飞翔公司所有生产环境禁止使用 Basic 认证，除非走 HTTPS 且配合其他安全措施。

假设鸣哥（内容运营）的 Bearer Token 泄露了，服务器如何撤销他的访问权限？JWT 的"无状态"特性在这里是优势还是劣势？

答案：

鸣哥负责飞翔公司公众号的内容发布，他的 Bearer Token（JWT）不小心在 GitHub 上泄露了。JWT 的"无状态"意味着服务器本身不保存会话信息，只通过签名验证 Token 是否合法——一个合法的 JWT 在过期前永远是"有效"的。

撤销方案：

  1. 黑名单机制（Token Blocklist）：服务器维护一个 Redis 黑名单，存储被撤销的 Token ID（jti 字段）。每次请求先查黑名单。飞翔公司的网关层由雁姐负责，她就用 Redis 存储已撤销的 Token，设置过期时间与 Token 一致。
# 飞翔公司 API 网关的 Token 校验逻辑（Python/Flask）
import redis
r = redis.Redis(host='redis.feixiang.net')

def check_token(token):
    # 1. 先验签
    payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
    jti = payload.get('jti')  # JWT ID，唯一标识
    
    # 2. 查黑名单
    if r.exists(f"blacklist:{jti}"):
        return False, "Token 已被撤销"
    
    return True, payload

# 撤销 Token（鸣哥泄露后，管理员操作）
def revoke_token(jti, exp):
    ttl = exp - int(time.time())
    if ttl > 0:
        r.setex(f"blacklist:{jti}", ttl, "revoked")
  1. 短有效期 + 刷新令牌：Access Token 只设 15 分钟有效期，配合 Refresh Token。泄露后最多损失 15 分钟。

无状态是优势还是劣势？

  • 优势：服务器不需要集中存储会话，水平扩展容易，微服务架构下各服务独立验签
  • 劣势：撤销困难，一旦签发就难以收回，必须引入额外的状态（黑名单）

在鸣哥这个场景中，无状态是劣势——如果是有状态的 Session，服务器直接删 Session 记录即可；但 JWT 必须额外引入 Redis 黑名单，破坏了"纯粹的无状态"。

翼王要求"所有内部系统必须 HTTPS + 认证"。如果某个旧系统只支持 Basic 且无法改造，你会建议用什么方案增强安全性？

答案：

飞翔公司有一个 2015 年上线的老财务系统，只支持 Basic 认证，代码已经找不到原始仓库，重构成本极高。直接暴露在公网等于把用户名密码送给黑客。

推荐方案：反向代理 + 现代认证层

  1. Nginx/Traefik 反向代理：老系统只监听 localhost，不直接对外暴露。前端用 Nginx 做反向代理，Nginx 负责 TLS 终止和现代认证（OAuth2/OIDC）。
# 飞翔公司老系统 Nginx 配置示例
server {
    listen 443 ssl http2;
    server_name legacy.finance.feixiang.net;
    
    # TLS 配置（翼王的硬性要求）
    ssl_certificate /etc/nginx/ssl/feixiang.crt;
    ssl_certificate_key /etc/nginx/ssl/feixiang.key;
    
    # 现代认证：用 auth_request 委托给统一认证中心
    location / {
        auth_request /auth;
        auth_request_set $auth_user $upstream_http_x_user;
        
        proxy_pass http://localhost:8080;
        proxy_set_header Authorization "Basic bGVnYWN5OmxlZ2FjeXBhc3M=";  # 固定内部 Basic
        proxy_set_header X-Remote-User $auth_user;
    }
    
    # 统一认证中心（OAuth2/OIDC）
    location = /auth {
        internal;
        proxy_pass http://auth.feixiang.net/verify;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_set_header X-Original-URI $request_uri;
    }
}

  1. VPN/Zero Trust 网络：老系统不暴露任何公网 IP，员工必须通过公司 VPN 或 Zero Trust 客户端（如 Cloudflare Tunnel）访问。

  2. API Gateway 封装：如果是 API 调用，用 Kong/AWS API Gateway 做外层认证，内层固定 Basic 凭证，外部调用者完全感知不到 Basic 的存在。

# 客户端调用流程（外部完全不知道内部是 Basic）
curl -H "Authorization: Bearer <modern-jwt>" \
     https://gateway.feixiang.net/api/legacy/finance/report

# Gateway 解密 JWT，验证权限，再向内转发 Basic 认证

凌叔（安全负责人）在飞翔公司推行的原则是："不能改老的，就包一层新的"。老系统像被装进了保险箱，外部攻击者面对的是现代安全体系，Basic 凭证只在内部可信网络中流转。