Wix

# Basic Access Authentication

  • 客户端请求了未授权网站
  • 服务端返回401
  • 客户端转跳登录页，输入密码，发送请求，发送密码
    • 拼接 user:pwd
    • base64编码
    • 添加请求头Authorization: Basic YWRtaW46cGFzc3dvcmQ=
  • 客户端解码验证

服务器将用户信息在一段时间内存储在缓存中，请求通过发送id来获取或验证身份。

  • 浏览器传递用户名密码（或者其他的登录方式）
  • 服务端验证通过，生成session_id，保存信息缓存中，返回set-cookie
  • 浏览器携带cookie发送请求
  • 根据session_id查找登录状态，返回资源

缺点：

  1. 非常不安全，Cookie 将数据暴露在浏览器中，增加了数据被盗的风险（容易被 CSRF 等攻击）
  2. Session 存储在服务端，增大了服务端的开销，用户量大的时候会大大降低服务器性能
const Koa = require('koa')
const Koa_Session = require('koa-session')
const redisStore = require("koa-redis");

const session_signed_key = [ // 这个是配合signed属性的签名key
  "some secret hurr"
]

const session_config = {
  key: 'koa:sess', /**  cookie的key。 (默认是 koa:sess) */
  maxAge: 4000, /**  session 过期时间，以毫秒ms为单位计算 。*/
  autoCommit: true, /** 自动提交到响应头。(默认是 true) */
  overwrite: true, /** 是否允许重写 。(默认是 true) */
  httpOnly: true, /** 是否设置HttpOnly，如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。  (默认 true) */
  signed: true, /** 是否签名。(默认是 true) */
  rolling: true, /** 是否每次响应时刷新Session的有效期。(默认是 false) */
  renew: false, /** 是否在Session快过期时刷新Session的有效期。(默认是 false) */
  store: (new Redis({ host: '127.0.0.1', port: 6379}))({ client: redisClient })
}

const app = new Koa()
app.keys = session_signed_key
app.use(Koa_Session(session_config, app))
app.use(ctx => {
  if (ctx.path === '/favicon.ico') return
  if (!ctx.session.logged) { // 如果登录属性为undefined或者false，对应未登录和登录失败
    ctx.session.logged = false
    if (checkUser(ctx.body.query)) {
      ctx.body = "登录成功"
      ctx.session.logged = true
    } else {
      ctx.body = "登录失败"
    }
  } else {
    ctx.body = "已登录"
  }
}
)

app.listen(3000)

最简单的session可以只是一个根据时间戳生成的随机字符串，作为唯一表示来存储着用户的状态。

# Token登录

Token 和 Session-Cookie 认证方式中的 Session ID 不同，并非只是一个标识符。Token 一般会包含 用户的相关信息，通过验证 Token 不仅可以完成身份校验，还可以获取预设的信息。

  • 浏览器传递用户名密码（或者其他的登录方式）
  • 服务端验证通过，生成token令牌，返回token令牌
  • 浏览器存储token，请求接口时携带token令牌Authorization: access_token
  • 校验token令牌，返回资源

token登录一种思想，而在实现上，可以根据业务去指定特定的具体实现，例如如何生成并定义token令牌

# JWT

JWT（JSON Web Token）是 Auth0 提出的通过对 JSON 进行加密签名来实现授权验证的方案，就是登录成功后将相关信息组成 JSON 对象，然后对这个对象进行某种方式的加密，返回给客户端，客户端在下次请求时带上这个 Token，服务端再收到请求时校验 token 合法性，其实也就是在校验请求的合法性。

JWT 实际是加密json数据后生成的字符串

Headers--jwt头部：

// 类别（typ）、加密算法（alg）
{
  "alg": "HS256",
  "typ": "JWT"
}

Claims--jwt载荷：

// 前五个是标准中定义的固定字段
{
  "iss": "Jehoshaphat Tse", // 该 JWT 的签发者
  "iat": 1441593502, // 在什么时候签发的。把头部和载荷分别进行 Base64 编码后得到两个字符串，然后再将这两个编码后的字符串用英文句号连接起来（头部在前），形成新的字符
  "exp": 1441594722, // 什么时候过期，这是 Unix 时间戳
  "aud": "www.example.com", // 接收该 JWT 的一方
  "sub": "mrsingsing@example.com", // 该 JWT 所面向的用户
  "name": "wix",
  "role": "admin"
}

Signature：jwt签名

// 将上述拼接后的字符串，用 alg 指定的算法（HS256）与私有密钥（Secret）进行加密。加密后的内容也是字符串，这个字符串就是签名

HMACSHA256(base64UrlEncode(Headers) + '.' + base64UrlEncode(Claims), SECREATE_KEY);

最后，把三部分拼接得到完整的 JWT。${Headers}.${Claims}.${Signature：jwt}

Header 部分和 Claims 部分如果被篡改，由于篡改者不知道密钥是什么，也无法生成新的 Signature 部分，服务端也就无法通过。

// token 生成
const router = require('koa-router')();
const jwt = require('koa-jwt');
const userModel = require('db');
const secretOrPublicKey = 'TOKEN_EXAMPLE';

router.post('/login', async ctx => {
  const data = ctx.request.body;
  const userInfo = await userModel.findOne({ name: data.name, password: data.password });
  let result = null;
  if (userInfo !== null) {
    // 根据用户信息签发 Token，设定有效时间为 2h
    const token = jwt.sign({ name: userInfo.name, _id: userInfo._id }, secretOrPublicKey, {
      expiresIn: '2h',
    });

    result = {
      code: 200,
      token: token,
      msg: '登录成功',
    };
  } else {
    result = {
      code: 400,
      token: null,
      msg: '登录失败',
    };
  }

  return (ctx.body = result);
});
// 前端获取
async function login(name, password) {
  const { code, token } = await axios.post('/login', { name, password })
  if (res.code === 200) {
  	localStorage.setItem('jwt', res.data.token);
  } else {
    console.log('登录失败');
  }
}
axios.interceptors.request.use(config => {
  const token = localStorage.getItem('token');
  config.headers.common['Authorization'] = 'Bearer ' + token;
  return config;
})
// 后端验证
const koa = require('koa');
const jwt = require('koa-jwt');
const app = new Koa();
const secretOrPublicKey = 'TOKEN_EXAMPLE';

app
  .use(jwt({ secret: secretOrPublicKey }))
  .unless({ path: [/\register/, /\/login/] });

// TODO 自动生成

# OAuth2开发授权

OAuth（开放授权）是一个开发标准，允许用户授权 第三方网站 访问他们存储在另外的服务提供商中的信息，而不需要接触到用户名和密码。为了保护数据的安全和隐私，第三方网站访问用户数据前都需要 显式地向用户征求授权。我们常见的 OAuth 认证服务的厂商有微信、QQ、支付宝等。

要让第三方得到第一方的权限有两种方法，一是你将账号密码提供给第三方应用，以便它们可以代表你来登陆账号并且访问数据；二是你通过 OAuth 授权第三方应用访问你的数据，而无需提供密码。

授权模式：

  • 授权码模式（Authorization Code Grant）
  • 隐式授权模式（Implicit Grant）
  • 密码模式（Resource Owner Password Credentials Grant）
  • 客户端模式（Client Credentials Grant）

无论哪种授权模式，都必须拥有四种必要的角色参与：第三方客户端、授权服务器、资源服务器，有的还有 用户（资源拥有者）。

# 授权码模式

第三方应用先申请一个授权码，然后再用该码获取令牌。需要第三方应用有自己的后端。

第一步，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

https://b.com/oauth/authorize?
  response_type=code& ## 表示要求返回授权码 code
  client_id=CLIENT_ID& ## 让 B 知道是谁在请求
  redirect_uri=CALLBACK_URL& ##  B 接受或拒绝请求后的跳转网址
  scope=read ## 要求的授权范围

第二步，用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

https://a.com/callback?code=AUTHORIZATION_CODE

第三步，A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。

第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。

# 隐式授权模式

如果第三方应用没有后端，是纯前端，将token放在前端，即没有了code这个中间层。

第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

https://b.com/oauth/authorize?
  response_type=token& ## 直接要求返回token
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

https://a.com/callback#token=ACCESS_TOKEN

注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。

# 密码模式

第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

上面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 B 的用户名和密码。

第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

# 凭证模式

适用于没有前端的命令行应用，即在命令行下请求令牌。

第一步，A 应用在命令行向 B 发出请求。

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 B 确认 A 的身份。

第二步，B 网站验证通过以后，直接返回令牌。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

# OpenID Connect（OIDC） 协议

OIDC是一个OAuth2上层的简单身份层协议。OAuth 2.0 用于授权，OpenID Connect 用于认证。

(身份验证)+ OAuth 2.0 = OpenID Connect

OAuth 不会立即提供用户身份，而是会提供用于授权的访问令牌。 OpenID Connect 使客户端能够通过认证来识别用户，其中，认证在授权服务端执行。它是这样实现的：在向授权服务端发起用户登录和授权告知的请求时，定义一个名叫openid的授权范围。在告知授权服务器需要使用 OpenID Connect 时，openid是必须存在的范围。

客户端发起的用于 OpenID Connect 认证请求 URI 会是如下的形式：

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=your_client_id&
 scope=openid%20contacts&
 redirect_uri=https%3A//oauth2.example.com/code

# 单点登录

针对于sso，有CAS协议，此外OAuth、OIDC也可以用来构建sso

  • cas：支持authentication
  • oauth：支持authorization
  • oidc：支持authentication、authorization

# 同域

当存在两个相同域名下的系统 A a.abc.com 和系统 B b.abc.com 时，以下为他们实现 SSO 的步骤：

  1. 用户访问某个子系统时（例如 a.abc.com），如果没有登录，则跳转至 SSO 认证中心提供的登录页面进行登录
  2. 登录认证后，服务端把登录用户的信息存储于 Session 中，并为用户生成对应的会话身份凭证附加在响应头的 Set-Cookie 字段中，随着请求返回写入浏览器中，并回跳到设定的子系统链接中
  3. 下次发送请求时，当用户访问同域名的系统 B 时，由于 A 和 B 在相同域名下，也是 abc.com，浏览器会自动带上之前的 Cookie。此时服务端就可以通过该 Cookie 来验证登录状态了。

这实际上使用的就是 Session-Cookie 认证的登录方式。

# 跨域——CAS

CAS（Central Authentication Service）中央授权服务，本身是一个开源协议，分为 1.0 版本和 2.0 版本。1.0 称为基础模式，2.0 称为代理模式，适用于存在非 Web 应用之间的单点登录。

CAS 的实现需要三方角色：

  • Client：用户
  • Server：中央授权服务，也是 SSO 中心负责单点登录的服务器
  • Service：需要使用单点登录鉴权的各个业务服务，serverA、serverB

CAS 的实现需要提供以下四个接口：

  • /login：登录接口，用于登录到中央授权服务
  • /logout：登出接口，用于从中央授权服务中登出
  • /validate：用于验证用户是否登录中央授权服务
  • /serviceValidate：用于让各个 Service 验证用户是否登录中央授权服务

CAS 票据：

  • TGT（Ticket Grangting Ticket）：TGT 是 CAS 为用户签发的 登录票据，拥有了 TGT，用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。当 HTTP 请求到来时，CAS 以此 Cookie 值（TGC）为 key 查询缓存中是否有 TGT，如果有，则表示用户已登录过。
  • TGC（Ticket Granting Cookie）：CAS Service 生成 TGC 放入自己的 Session 中，而 TGC 就是这个 Session 的唯一标识（SessionID），以 Cookie 形式放到浏览器端，是 CAS Service 用来明确用户身份的凭证
  • ST（Service Ticket）：ST 是 CAS 为用户签发的访问某个 Service 的票据。用户访问 Service 时，Service 发现用户没有 ST，则要求用户去 CAS 获取 ST。用户向 CAS 发出 ST 的请求，CAS 发现用户有 TGT，则签发一个 ST，返回给用户。用户拿着 ST 去访问 Service，Service 拿 ST 去 CAS 验证，验证通过后，允许用户访问资源。

实际上 TGC 和 TGT 是维护客户端与中央授权服务登录状态的会话身份凭证的 key-value 键名值，而 ST 票据则是资源服务向中央授权服务获取用户登录状态、信息的交换凭证，只不过资源服务需要经用户的“手”上才能获取到该票据。

  1. 用户访问系统 A 的受保护资源（域名是 a.abc.com），系统 A 检测出用户处于 未登录 状态，重定向（应答码 302）至 SSO 服务认证中心的登录接口，同时地址参数携带登录成功后回跳到系统 A 的页面链接（跳转的链接形如 sso.abc.com/login?service=https%3A%2F%2Fwww.a.abc.com）

  2. 由于请求没有携带 SSO 服务器上登录的票据凭证（TGC），所以 SSO 认证中心判定用户处于 未登录 状态，重定向用户页面至 SSO 的登录界面，用户在 SSO 的登录页面上进行登录操作。

  3. SSO 认证中心校验用户身份，创建用户与 SSO 认证中心之间的会话，称为 全局会话，同时创建 授权令牌（ST），SSO 带着授权令牌跳转回最初的系统 A 的请求地址：

    • 重定向地址为之前写在 query 中的系统 A 的页面地址
    • 重定向地址的 query 中包含 SSO 服务器派发的 ST
    • 重定向的 HTTP 响应中包含写 Cookie 的 Header。这个 Cookie 代表用户在 SSO 中的登录状态，它的值就是 TGC

  4. 浏览器重定向至系统 A 服务地址，此时重定向的 URL 中携带着 SSO 服务器生成的 ST

  5. 系统 A 拿着 ST 向 SSO 服务器发送请求，SSO 服务器验证票据的有效性。验证成功后，系统 A 知道用户已经在 SSO 登录了，于是系统 A 服务器使用该令牌创建与用户的会话，称为 局部会话，返回受保护网页资源

  6. 之后用户访问系统 B 受保护资源（域名 b.abc.com），系统 B 检测出用户处于 未登录 状态，跳转至 SSO 服务认证中心，同时地址参数携带授权令牌 ST（每次生成的 ST 都是不一样的）登录成功后回跳的链接

  7. SSO 认证中心发现用户已登录，跳转回系统 B 的地址，并附上令牌

  8. 系统 B 拿到令牌，去 SSO 认证中心校验令牌是否有效，SSO 认证中心校验令牌，返回有效，注册系统 B

  9. 系统 B 使用该令牌创建与用户的局部会话，返回受保护资源

至此整个登录流程结束，而在实际开发中，基本上都会根据 CAS 增加更多的判断逻辑，比如，在收到 CAS Server 签发的 ST 后，如果 ST 被 Hacker 窃取，并且 Client 本身没来得及去验证 ST，被 Hacker 抢先一步验证 ST，怎么解决。此时就可以在申请 ST 时添加额外验证因子（如 IP、SessionID 等）。