wabicai的个人空间

# 12.常见登录方式

https://juejin.cn/post/6933115003327217671

  • Cookie + Session 登录
  • Token 登录
  • SSO 单点登录
  • OAuth 第三方登录

  1. 应用场景 Cookie + Session  的登录方式是目前最经典的一种登录方式，现在仍然有大量的企业在使用。

  2. 流程

    1. 用户访问 a.com/pageA，并输入密码登录。
    2. 服务器验证密码无误后，会创建 SessionId，并将它保存起来。
    3. 服务器端响应这个 HTTP 请求，并通过 Set-Cookie 头信息，将 SessionId 写入 Cookie 中。 Cookie + Session 实现流程

  3. 优缺陷：

    1. 服务端存放大量 SessionId，服务端压力大
    2. 负载均衡的时候 SessionId 不好同步
    3. 会有 CSRF 攻击风险

      服务器端的 SessionId 可能存放在很多地方，例如：内存、文件、数据库等。

# Token 登录

  1. 应用场景 Cookie + Session  的登录方式是目前最经典的一种登录方式，现在仍然有大量的企业在使用。

  2. 流程

    • 用户首次登录时：
      1. 用户访问 a.com/pageA，输入账号密码，并点击登录。
      2. 服务器端验证账号密码无误，创建 Token。
      3. 服务器端将 Token 返回给客户端，由客户端自由保存。
      4. 用户访问 a.com/pageB 时，带上第一次登录时获取的 Token。
        1. 服务器端验证该 Token ，有效则身份验证成功，无效则踢回重新的登录。

  3. 优缺点

    1. 服务器端不需要存放 Token
    2. Token 可以存放在前端任何地方，可以不用保存在 Cookie 中，提升了页面的安全性。
    3. Token 下发之后，只要在生效时间之内，就一直有效，但是如果服务器端想收回此 Token 的权限，并不容易。
    4. 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输
    5. JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

  4. Token 生成方式

    1. header（头信息），playload（消息体），signature（签名）。
    2. header 部分指定了该 JWT 使用的签名算法；
    3. playload 部分表明了 JWT 的意图；
    4. signature 部分为 JWT 的签名，主要为了让 JWT 不能被随意篡改。
    5. 关键在：signature，里面包含一个服务端才有的密钥

# SSO 单点登录

单点登录是指在同一帐号平台下的多个应用系统中，用户只需登录一次，本质就是在多个应用系统中共享登录状。 实现单点登录的关键在于，如何让 Session Id（或 Token）在多个域中共享。

# 实现方式：

  1. 父域 Cookie
    1. Cookie 有一个特点，即父域中的  Cookie  被子域所共享，也就是说，子域会自动继承父域中的  Cookie。
    2. 将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径
    3. 所有的子域应用就都可以访问到这个 Cookie
    4. 此种实现方式比较简单，但不支持跨主域名。
  2. 认证中心
    1. 此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。
    2. 首次登录 a.com，302 跳转至 认证中心， 生成 token，客户端将 token 写入 cookie， （此时客户端有 2 个 Cookie 分别存有 a.com 和 sso.com 的登录态）
    3. 访问 a.com， a.com=>认证中心验证 token，通过，直接访问。
    4. 访问 b.com，重定向 认证中心，携带 a.com 的 Cookie，验证成功，下发 token 给 b.com，登录成功。
  3. LocalStorage 跨域
    1. 原理：同一浏览器的相同域名和端口的不同页面间可以共享相同的 localStorage，但是不同页面间无法共享 sessionStorage 的信息。
    2. 前后端分离的情况下，完全可以不使用 Cookie
    3. 可以将 Session Id （或 Token ）保存到浏览器的 LocalStorage
    4. 实现方案：postMessage 和 iframe 相结合的方法。
    5. safari 浏览器的默认限制，父页面无法向 iframe 里的跨域页面传递信息。可以通过 url 传值的方法来实现跨域存储功能，可以支持超过 64k 个字符的长度
    6. Safari 隐私限制 iframe 内不能操作 localstorage 怎么破……必须关闭隐私=>跨站跟踪数据 才行。
    7. 此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域。

# OAuth 第三方登录

QQ 微信 微博等 OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。 通俗说，OAuth 就是一种授权的协议，只要授权方和被授权方遵守这个协议去写代码提供服务，那双方就是实现了 OAuth 模式。

# OAuth 机制实现流程

!()

  1. 首先，a.com 的运营者需要在微信开放平台注册账号，并向微信申请使用微信登录功能。
  2. 申请成功后，得到申请的 appid、appsecret。 3. 用户在 a.com 上选择使用微信登录。
  3. 这时会跳转微信的 OAuth 授权登录，并带上 a.com 的回调地址。
  4. 用户输入微信账号和密码，登录成功后，需要选择具体的授权范围，如：授权用户的头像、昵称等。
  5. 授权之后，微信会根据拉起 a.com?code=123 ，这时带上了一个临时票据 code。
  6. 获取 code 之后， a.com 会拿着 code 、appid、appsecret，向微信服务器申请 token，验证成功后，微信会下发一个 token。
  7. 有了 token 之后， a.com 就可以凭借 token 拿到对应的微信用户头像，用户昵称等信息了。
  8. a.com 提示用户登录成功，并将登录状态写入 Cookie，以作为后续访问的凭证。

# 总结

上面四种登录实现方案，基本囊括了现有的登录验证方案，原理以及实现流程基本都了解。

  • Cookie + Session 历史悠久，适合于简单的后端架构，需开发人员自己处理好安全问题。
  • Token 方案对后端压力小，适合大型分布式的后端架构，但已分发出去的 token ，如果想收回权限，就不是很方便了。
  • SSO 单点登录，适用于中大型企业，想要统一内部所有产品的登录方式的情况。
  • OAuth 第三方登录，简单易用，对用户和开发者都友好，但第三方平台很多，需要选择合适自己的第三方登录平台。
Last Updated: 6/3/2024, 1:08:34 AM

← 13.HTTP缓存 →