cookie-session vs JWT vs oauth vs CAS

CAS vs oAuth.md

都可以做 SSO

• CAS: 多个系统只需登录一次，无需重复登录
• oAuth: 第三方系统访问主系统资源，用户无需将在主系统的账号告知第三方，只需通过主系统的授权，第三方就可使用主系统的资源（如：APP1需使用微信支付，微信支付会提示用户是否授权，用户授权后，APP1就可使用微信支付功能了）

cookie-session vs JWT.md

JWT (JSON Web Token)

JWT是一种无状态的鉴权机制。将用户登录后的一些信息（比如用户Id）和过期时间等信息存储在一个加密过的字符串中,当服务器收到请求的时候，进行解密并直接使用信息 JWT的组成：使用base64编码描述jwt的头部、使用base64编码的payload，以及加密签名

缺点: 服务器无法像session一样方便地管理用户登录状态

工作流程:

1. 用户输入登录信息
2. 服务器验证登录信息，如果正确就返回一个已签名(数字签名)的token
3. 这个token存储在客户端，最常见的是存储在localstorage中，但是也可以存在session storage和cookie中
4. 之后向服务器发送的请求都会带上这个token
5. 服务器解码JWT，如果token是有效的则处理这个请求
6. 如果用户退出登录，token会在客户端销毁，这一步与服务器无关

cookie-session

流程:

1. 用户输入登录信息
2. 服务器验证登录信息是否正确，如果正确就创建一个session,并把session存入数据库
3. 服务器端会向客户端返回带有sessionID的cookie
4. 在接下来的请求中，服务器将把sessionID与数据库中的相匹配，如果有效则处理该请求
5. 如果用户登出app，session会在客户端和服务器端都被销毁

对比

扩展性

随着应用程序的扩大和用户数量的增加，你必将开始水平或垂直扩展。session数据通过文件或数据库存储在服务器的内存中。在水平扩展方案中，你必须开始复制服务器数据，你必须创建一个独立的中央session存储系统，以便所有应用程序服务器都可以访问。否则，由于session存储的缺陷，你将无法扩展应用程序。解决这个挑战的另一种方法是使用 sticky session。你还可以将session存储在磁盘上，使你的应用程序在云环境中轻松扩展。这类解决方法在现代大型应用中并没有真正发挥作用。建立和维护这种分布式系统涉及到深层次的技术知识，并随之产生更高的财务成本。在这种情况下，使用JWT是无缝的;由于基于token的身份验证是无状态的，所以不需要在session中存储用户信息。我们的应用程序可以轻松扩展，因为我们可以使用token从不同的服务器访问资源，而不用担心用户是否真的登录到某台服务器上。你也可以节省成本，因为你不需要专门的服务器来存储session。为什么？因为没有session！ 注意：如果你正在构建一个小型应用程序，这个程序完全不需要在多台服务器上扩展，并且不需要RESTful API的，那么session机制是很棒的。 如果你使用专用服务器运行像Redis那样的工具来存储session，那么session也可能会为你完美地运作！

安全性

JWT签名旨在防止在客户端被篡改，但也可以对其进行加密，以确保token携带的claim 非常安全。JWT主要是直接存储在web存储（本地/session存储）或cookies中。 JavaScript可以访问同一个域上的Web存储。这意味着你的JWT可能容易受到XSS（跨站脚本）攻击。恶意JavaScript嵌入在页面上，以读取和破坏Web存储的内容。事实上，很多人主张，由于XSS攻击，一些非常敏感的数据不应该存放在Web存储中。一个非常典型的例子是确保你的JWT不将过于敏感/可信的数据进行编码，例如用户的社会安全号码。

最初，我提到JWT可以存储在cookie中。事实上，JWT在许多情况下被存储为cookie，并且cookies很容易受到CSRF（跨站请求伪造）攻击。预防CSRF攻击的许多方法之一是确保你的cookie只能由你的域访问。作为开发人员，不管是否使用JWT，确保必要的CSRF保护措施到位以避免这些攻击。 现在，JWT 和 session ID 也会暴露于未经防范的重放攻击。建立适合系统的重放防范技术，完全取决于开发者。解决这个问题的一个方法是确保JWT具有短期过期时间。虽然这种技术并不能完全解决问题。然而，解决这个挑战的其他替代方案是将JWT发布到特定的IP地址并使用浏览器指纹。

注意：使用HTTPS / SSL确保你的Cookie和JWT在客户端和服务器传输期间默认加密。这有助于避免中间人攻击！

RESTful API 服务

现代应用程序的常见模式是从RESTful API查询使用JSON数据。目前大多数应用程序都有RESTful API供其他开发人员或应用程序使用。由API提供的数据具有几个明显的优点，其中之一就是这些数据可以被多个应用程序使用。在这种情况下，传统的使用session和Cookie的方法在用户认证方面效果不佳，因为它们将状态引入到应用程序中。

RESTful API的原则之一是它应该是无状态的，这意味着当发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。保持API无状态，不产生附加影响，意味着维护和调试变得更加容易。

另一个挑战是，由一个服务器提供API，而实际应用程序从另一个服务器调用它的模式是很常见的。为了实现这一点，我们需要启用跨域资源共享（CORS）。Cookie只能用于其发起的域，相对于应用程序，对不同域的API来说，帮助不大。在这种情况下使用JWT进行身份验证可以确保RESTful API是无状态的，你也不用担心API或应用程序由谁提供服务。

---

• https://juejin.im/post/5a437441f265da43294e54c3
• https://www.jianshu.com/p/d6d0cd4fae6e

oAuth.md

概述

oAuth 是一个关于授权的开放网络标准，目前 2.0 版。

oAuth 的作用就是让客户端安全可控地获取用户授权，与服务提供商互动

• Third-party application: 第三方应用（『客户端』，就是开发者）
• HTTP service: HTTP服务提供商（如 github ）
• Resource Owner: 资源所有者（用户）
• User Agent: 用户代理（浏览器）
• Authorization: 认证服务器，即服务提供商专门用来处理认证的服务器
• Resource server： 资源服务器，即 github 存在用户生成的资源的服务器，和认证服务器可以是同一台服务器也可以是不同服务器

思路

oAuth 在『客户端』与『服务提供商』之间，设置了一个授权层（authorization layer）。客户端不能直接登录『服务提供商』，只能登录授权层，这样将用户和『客户端』区分开。

• 『客户端』登录授权层使用 token（令牌）
• 用户登录服务提供商使用的是密码，用户在登录时可以指定授权层的权限范围和有效期

『客户端』登录授权层后，『服务提供商』根据 token 的权限范围和有效期，向『客户端』开放用户存储的资料。

流程

在人人网开放平台创建应用

得到 API KEY 和 Secret Key:

一定要填写回调：

用户使用 oAuth 是这个流程：

• A. 用户打开客户端，客户端要求用户给授权

  

• B. 用户同意授权给客户端

  

  http://graph.renren.com/oauth/grant
  
  * client_id=e9677ff99be74072ba2c59cd2dad944b
  * redirect_uri=http%3A%2F%2Flocalhost%3A3333%2Fmain
  * response_type=code
  * display=page
  * secure=true
  * origin=00000
  

  用户同意授权之后，页面会跳转到指定的回调地址。 这里我使用了 http://localhost:3333 本地地址，并且带上了『应用授权码』（code参数）

• C. 客户端使用上一步得到的授权，向认证服务器申请 token

  https://graph.renren.com/oauth/token
  
  /*params*/
  * grant_type=authorization_code
  * client_id=e9677ff99be74072ba2c59cd2dad944b
  * redirect_uri=http://localhost:3333/main
  * client_secret=a3ab032aa239488abf081019b5fa2385
  * code=vgHiJEY3Bc4GctffDNXQ1bu1TsUTZn98
  

  把 code 和 secret key 一起发送申请token

  这一步在客户端的后台服务器上完成，对用户不可见，这很重要！因为你的 secret key 是不能暴漏出来的！

• D. 认证服务器对客户端进行认证后，确认无误，同意发放 token

  

• E. 客户端使用 token，向资源服务器申请获取资源

  使用 token 调用 API

• F. 资源服务器确认 token 无误，同意向客户端开放资源

授权模式

• 授权码模式
• 简化模式
• 密码模式
• 客户端模式

刚才说的人人网使用的就是授权码模式，这也是功能最完整、流程最严密的授权模式。特点是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

---

• http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

• HTTP验证大法(Basic Auth,Session, JWT, Oauth, Openid)

微信登录 Token 案例

FE

前端重定向到一个微信提供的地址:

login = () => {
    location.href = `https://open.weixin.qq.com/connect/qrconnect?appid=${APP_ID}&redirect_uri=${encodeURIComponent('http://localhost:3000/api/wechat/callback')}&response_type=code&scope=snsapi_login&state=${Math.random()}#wechat_redirect`
  }

然后到了这个页面，微信扫码登录:

Server

扫码登录后跳转到 callback 页面:

router.get('/wechat/callback', async(ctx) => {
  // code 是微信平台带过来的，需要用 code 申请 token
  const { code } = ctx.request.query

  // 申请 token
  const res = await axios.get(`https://api.weixin.qq.com/sns/oauth2/access_token?appid=${APPID}&secret=${APPSECRET}&code=${code}&grant_type=authorization_code`)

  const {
    access_token,
    refresh_token,
    openid,
    unionid,
  } = res.data

  // 有了 access_token 可以再去调用微信 API 获得头像等用户信息
  // 略
  
  // 这里把 openid 作为 cookie 带到前端，其实用 token 好一点
  ctx.cookies.set('uid', openid)
  ctx.response.redirect('/')
})

然后把 token 存在 redis 里，每次请求 cookie 里的 token 都会带上，验证是否合法，不合法则重新登录，略。