网易二面：常见的登录鉴权方法有哪些？

程序员飞鱼
66 阅读5分钟

文章内容收录到个人网站，方便阅读：hardyfish.top/

登录鉴权的核心任务是两件事：认证（Authentication，确认“是谁”）与授权（Authorization，确认“能做什么”）。

工程上通常把“登录”视为建立认证态的过程，把“鉴权”视为每次访问资源时的权限校验。

常见方法大致沿着“状态放哪里、凭证怎么传、凭证怎么失效”这条主线展开。

Cookie + Session（服务端会话）

最传统、也最符合“浏览器站点登录”直觉的方案。

登录成功后，服务端创建 Session（会话），并把 session_id 写入浏览器 Cookie（浏览器自动随请求携带的键值对）。

  • 工作方式

    • 用户提交账号密码
    • 服务端校验后生成 session_id，把会话数据存到内存/Redis/数据库
    • 浏览器后续请求自动携带 Cookie，服务端通过 session_id 找回会话并鉴权

  • 优点

    • 权限即时生效、易于踢下线（删除/失效 Session）
    • 适合传统 Web、管理后台

  • 局限与要点

    • 服务端有状态，横向扩展依赖共享存储（常见用 Redis）
    • 需要重点防护 CSRF（跨站请求伪造），一般配合 SameSite、CSRF Token
    • Cookie 安全属性：HttpOnly、Secure、SameSite 需合理配置

Token（无状态令牌，典型是 JWT）

登录后服务端签发一个 Token（令牌），客户端保存并在请求时携带，服务端通过签名/校验规则判定合法性。

最常见实现是 JWT（JSON Web Token，一种自包含的签名令牌格式）。

  • 工作方式

    • 登录成功后签发 token（JWT 或自定义随机串）
    • 客户端通过 Authorization: Bearer <token> 发送
    • 服务端校验签名、过期时间、必要的声明（claims）并鉴权

  • 优点

    • 服务端可做到“少状态”甚至无状态，易扩展、适合 API/移动端
    • 跨域与非浏览器客户端更友好

  • 局限与要点

    • 失效与撤销更难：JWT 自包含导致“签发即有效直到过期”，常需黑名单/短过期+刷新机制
    • Token 存储位置决定风险：放 LocalStorage 易受 XSS 影响；放 Cookie 又要面对 CSRF
    • JWT 不是加密，默认是签名；敏感信息不应直接放 claims

Access Token + Refresh Token（短期访问 + 长期续期）

为解决 Token 过期与频繁登录之间的矛盾，常用“双 Token”机制：Access Token（短有效期）用于每次请求；

Refresh Token（长有效期）用于换取新的 Access Token。

  • 工作方式

    • Access Token 5–30 分钟过期（常见口径），Refresh Token 可更长
    • Access Token 过期时用 Refresh Token 调用刷新接口换新
    • Refresh Token 通常需要服务端存储并支持吊销（旋转与黑名单）

  • 关键实践

    • Refresh Token Rotation（刷新令牌轮换）：每次刷新都发新的 refresh token，旧的立刻失效
    • 设备维度管理：一台设备一个 refresh token，便于单点退出
    • 风控：异常地理位置、UA 变化、刷新频率异常触发再认证

OAuth 2.0 / OpenID Connect（第三方登录与统一身份）

面向“用微信/Google/企业统一账号登录”的场景。

OAuth 2.0 是授权框架（解决“授权第三方访问资源”），OpenID Connect（OIDC） 在 OAuth 2.0 上补齐“登录身份”能力（提供 id_token 等）。

  • 常见流程

    • 授权码模式（Authorization Code）+ PKCE：移动端与 SPA 常用，安全性较高
    • 服务端应用：用授权码换取 token，再获取用户信息

  • 优点

    • 统一身份体系，减少自建密码体系风险
    • 适合多应用、多系统的单点登录

  • 局限与要点

    • 需要理解授权服务器（Authorization Server）与资源服务器（Resource Server）的边界
    • 回调地址、state/nonce、PKCE 校验是安全关键点

SSO（单点登录：CAS / SAML / OIDC）

企业内多系统互通时常见：一次登录，多处生效。常见协议与实现包括：

  • SAML 2.0（更偏企业与传统系统）：浏览器重定向携带断言（Assertion），适合与企业 IdP（身份提供方）对接

  • CAS（Central Authentication Service）：高校与传统内部系统常见

  • OIDC SSO：现代化、与 OAuth 生态兼容度高

  • 典型关注点

    • 会话范围与登出：单点登出（SLO）往往比单点登录难
    • 跨域 Cookie、重定向链路与安全校验（state、签名、时间戳）

API Key / HMAC 签名（机器到机器的鉴权）

面向“系统调用系统”的场景，不一定有“登录”概念。

常见做法是给调用方发 API Key，并用 HMAC（基于密钥的哈希消息认证码）对请求进行签名，防篡改、防重放。

  • 工作方式

    • 请求中带 keyId + timestamp + nonce + signature
    • 服务端用共享密钥复算签名并校验时间窗与 nonce

  • 适用场景

    • OpenAPI、支付回调、Webhook、内部服务调用

  • 要点

    • 必须做重放防护（nonce + 时间窗 + 去重存储）
    • 密钥轮换与权限最小化（按应用/按环境发放）

多因素认证与无密码登录（增强认证强度）

这类不是独立的“会话形态”，而是登录阶段的增强手段，经常与上述任何一种会话/Token 方案组合使用。

  • MFA/2FA（多因素认证）：短信/邮件验证码、TOTP（如 Google Authenticator）、Push、硬件 Key

  • Passkeys/WebAuthn（通行密钥）：基于公私钥与设备生物识别/安全芯片，逐步替代密码

  • 要点

    • 风险分级触发：异地登录、敏感操作、异常设备时要求二次验证
    • 恢复流程与社工防护：找回机制往往是薄弱点

方法选择的工程取舍（常用组合）

  • 浏览器站点/管理后台：Cookie + Session（配 CSRF 防护）或 Cookie 承载短期 Token
  • 移动端/开放 API：Bearer Token（Access/Refresh）
  • 第三方登录：OIDC（或 OAuth 2.0 + 用户信息接口）
  • 企业多系统：SAML 或 OIDC 形态的 SSO
  • 系统对系统：API Key + HMAC 签名，或 mTLS（双向 TLS）增强链路身份

容易混淆的术语对照

  • 认证：证明身份（账号密码、短信码、Passkey）
  • 鉴权/授权：校验权限（RBAC 角色权限、ABAC 属性权限）
  • Session：服务端保存登录态
  • Token：客户端持有的凭证
  • JWT：Token 的一种格式（自包含、可签名）
  • SSO：跨系统共享认证态的一套机制与流程
avatar
文章
阅读
粉丝