聊一聊那些认证方式

[Pines-Cheng]

• OAuth是一个关于授权（authorization）的开放网络标准。The OAuth 2.0 Authorization Framework
• JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案。JSON Web Token (JWT)
• 基于角色的访问控制 (Role-based access control, RBAC) 对于权限设计还是挺有参考的。
• Node 权限相关：node_acl，rbac。
• 一个支持访问控制模型的认证库，支持 Node.js 和 Browser 的 ACL, RBAC, ABAC ：Node-Casbin

---

SSO

• SSO（Single Sign On）单点登录 是一种架构，一种设计思想
• CAS（Central Authentication Service）中心授权服务 是一个开源的协议，是SSO的一种具体实现，当然SSO 还有其它实现手段比如cookie的方式（同域名的场景）。
• Auth 是一种授权协议，不涉及具体的代码，只是表示一种约定的流程和规范。OAuth协议一般用于用户决定是否把自己在某个服务商上面的资源（比如：用户基本资料、照片、视频等）授权给第三方应用访问。此外，OAuth2.0协议是OAuth协议的升级版，现在已经逐渐成为单点登录（SSO）和用户授权的标准。

单点登录英文全称Single Sign On，简称就是SSO。它的解释是：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。

同域下的单点登录是巧用了Cookie顶域的特性。如果是不同域呢？不同域之间Cookie是不共享的，怎么办？

这里我们就要说一说CAS流程了，这个流程是单点登录的标准流程。

OAuth

node-oauth

OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。

"云冲印"怎样获得用户的授权呢？

传统方法是，用户将自己的Google用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。

（1）"云冲印"为了后续的服务，会保存用户的密码，这样很不安全。

（2）Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。

（3）"云冲印"拥有了获取用户储存在Google所有资料的权力，用户没法限制"云冲印"获得授权的范围和有效期。

（4）用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。

（5）只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的。

在详细讲解OAuth 2.0之前，需要了解几个专用名词。它们对读懂后面的讲解，尤其是几张图，至关重要。

（1） Third-party application：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"云冲印"。

（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Google。

（3）Resource Owner：资源所有者，本文中又称"用户"（user）。

（4）User Agent：用户代理，本文中就是指浏览器。

（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。

（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

知道了上面这些名词，就不难理解，OAuth的作用就是让"客户端"安全可控地获取"用户"的授权，与"服务商提供商"进行互动。

OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

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

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。

• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

JWT（JSON Web Token）

JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案。

传统登陆后，服务器向用户返回一个 session_id，写入用户的 Cookie。用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。

• 一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。
• 另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。

JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样。

{
  "姓名": "张三",
  "角色": "管理员",
  "到期时间": "2018年7月1日0点0分"
}

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名（详见后文）。

它是一个很长的字符串，中间用点（.）分隔成三个部分。注意，JWT 内部是没有换行的，这里只是为了便于展示，将它写成了几行。

JWT 的三个部分依次如下。

• Header（头部）
• Payload（负载）
• Signature（签名）

Signature 部分是对前两部分的签名，防止数据篡改。 ⚠️注意：Header 和 Payload 都是 JSON 的 base64，是完全裸奔的！

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

缺点

• JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
• JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

解码、验证和生成 JWT：https://jwt.io/

RBAC

基于角色的访问控制 (Role-based access control, RBAC) 是一种安全功能，用于控制用户对通常仅限于超级用户的任务的访问。通过对进程和用户应用安全属性，RBAC 可以向多个管理员分派超级用户功能。进程权限管理通过特权实现。用户权限管理通过 RBAC 实现。

与超级用户模型（管理员对系统要么具有全部控制权要么毫无控制权）相比，基于角色的访问控制 (Role-based access control, RBAC) 是一种更为安全的方法。使用 RBAC，可以在更精细的级别上强制执行安全策略。RBAC 采用最小特权的安全原则。最小特权表示用户仅具有执行某项作业所必需的特权。普通用户具有足够特权来使用其应用程序、检查其作业状态、打印文件、创建新文件等。超出普通用户功能以外的功能将分组到各权限配置文件中。如果用户将要执行的作业要求具有某些超级用户功能才能执行，这些用户将承担拥有适当权限配置文件的角色。

RBAC 会将超级用户功能收集到权限配置文件中。这些权限配置文件将指定给称为角色的特殊用户帐户。然后，用户可以承担某个角色，以执行要求具有某些超级用户功能才能执行的作业。

分层的 Node Role Based Access Control：https://github.com/seeden/rbac

ACL

ACL，是Access Control List的简写，中文名称叫做“访问控制列表”。它是由一系列条件规则（即描述报文匹配条件的判断语句）组成， 这些条件规则可以是报文的源地址、目的地址、端口号等，是一种应用在网络设备各种软硬接口上的的指令列表。

Node 应用的 Access control lists：https://github.com/optimalbits/node_acl

SAML

安全性断言标记语言 (SAML) 是一项 OASIS 开放式标准，用于表示和交换用户身份、认证和属性信息。SAML 断言是一种 XML 格式的令牌，用于在单点登录请求的完成过程中将用户的身份提供者中的用户身份和属性信息传输至可信服务提供者。

OpenID

OpenID是最早提出的一种无密码登录。

它的设想是这样的：互联网上每一个网址（URL），都指向一个独一无二的网页，这说明网址具有唯一性。因此，可以用网址来标识用户。

所以，使用OpenID的网站，不要求用户输入"用户名"，而要求用户输入一个代表其身份的网址。然后，向该网址进行求证，如果得到证实，就允许用户登录，从而实现"无密码登录"。

OpenID有两个很大的缺点：一是需要服务器端支持，二是使用网址表示身份，违背直觉，普通用户难以理解。因此，始终无法得到推广。

OpenID的实质，是让第三方网站认证用户身份。那么很显然，这等同于用户在第三方网站登录。

因此，可以直接告诉用户，使用第三方帐号登录（前提是对方支持OpenID）。

参考

• JSON Web Token 入门教程
• 理解OAuth 2.0
• SAML 2.0 Web 浏览器单点登录
• 使用 RBAC 鉴权
• 基于角色的访问控制（概述）
• 单点登录（SSO）的设计与实现
• 单点登录（SSO）看这一篇就够了