Angular应用存储auth token的最佳方案及sessionStorage异常问题求解

你遇到的刷新前拿不到sessionStorage值的问题，基本不是sessionStorage本身的缺陷，大概率是以下几个常见场景导致的：

• 存token的时机晚于你后续接口调用的时机：登录接口是异步请求，你在登录请求还没返回成功的时候就发起了需要带token的请求，此时sessionStorage里还没写入值，自然拿到undefined
• Angular服务单例的状态没有同步更新：如果你的请求拦截器是从自定义的AuthService里拿token，而AuthService只在初始化的时候读了一次sessionStorage，登录后你只更新了sessionStorage没更新AuthService里的内存变量，拦截器读到的还是旧的空值，就会出现你说的「必须刷新才能拿到」——因为刷新后AuthService重新初始化，会重新读sessionStorage里已经存好的值
• 存/取的时候key写错了，或者存的时候没有做字符串序列化：sessionStorage只能存字符串，如果你直接把Object类型的token响应塞进去，会被转成[object Object]，取的时候解析失败就会拿到undefined

第一步：修复现有sessionStorage方案的问题 #

先按下面的步骤排查修正，就能实现无需刷新正常使用token：

1. 确保存token的操作在登录请求的成功回调里执行，避免异步时序问题：

// 登录请求成功后的处理逻辑示例
login(userInfo: {username: string, password: string}) {
  this.http.post('/api/login', userInfo).subscribe(res => {
    // 假设res.data.token是接口返回的token字符串
    window.sessionStorage.setItem('auth_token', res.data.token);
    // 同步更新AuthService里的内存token变量
    this.authToken.next(res.data.token);
  })
}

2. 给Angular请求拦截器加双重获取逻辑，优先读内存的token变量，内存没有再读sessionStorage，避免内存状态和存储不同步：

@Injectable()
export class AuthInterceptor implements HttpInterceptor {
  constructor(private authService: AuthService) {}

  intercept(req: HttpRequest<any>, next: HttpHandler) {
    // 优先从authService的内存变量拿，拿不到再读sessionStorage
    const token = this.authService.authToken.value || window.sessionStorage.getItem('auth_token');
    if (token) {
      req = req.clone({
        setHeaders: {
          Authorization: `Bearer ${token}`
        }
      });
    }
    return next.handle(req);
  }
}

3. 不要在Angular的APP_INITIALIZER或者根组件初始化阶段就发起需要鉴权的请求，等登录流程完成之后再触发后续接口调用。

可选替代存储方案 #

如果不想用sessionStorage，也可以根据业务场景选择下面的方案：

• localStorage：持久化存储，只要用户不清缓存，关闭浏览器再打开也还能拿到token，适合做「记住我」功能，缺点是XSS攻击可以直接盗取token
• 内存变量 + 路由守卫：把token存在AuthService的BehaviorSubject里，只在内存持有，刷新页面就需要重新登录，安全性最高，适合对安全要求极高的内部系统
• HttpOnly Secure Cookie：如果AdonisJS后端支持的话，直接把token存在HttpOnly的Cookie里，前端完全不需要管存储逻辑，请求会自动带Cookie，还能避免XSS盗取token，是目前最推荐的鉴权存储方案，只需要前后端联调的时候把withCredentials属性打开即可

内容的提问来源于stack exchange，提问作者Noble Eugene