目录

• 分布式微服务系统主流常用的登录方案
• 基于JWT的单点登录解决方案
• 基于CAS同公司不同域的单点登录解决方案
• 基于Auth2.0之第三方登录
  • 授权模式

分布式微服务系统主流常用的登录方案

前言: 单点登录其实是一个概念，主要是为了解决一次登录，多系统(本系统或外部系统)之间不需要重复登录的问题，就目前来说，主流的解决方案针对业务场景分为3个方向:

• 1、同一公司，同父域下的单点登录解决方案

  如[http://map.baidu.com] [http://www.baidu.com] [http://image.baidu.com]

  基于cookie开源项目代表: JWT(https://jwt.io/)；会详细介绍和实现；

• 2、同一公司，不同域下的单点登录解决方案

  如[http://www.taobao.com] [http://www.tmall.com]

  基于中央认证服务器开源项目代表:CAS(https://github.com/apereo/cas)； https://www.apereo.org/projects/cas

• 3、不同公司之间，不同域下的 第三方登录功能实现

  如第三方网站支持qq登录，微信登录，微博登录等；

  基于OAuth2.0 协议各大公司自己的支持；

基于JWT的单点登录解决方案

首先我们看一下图形，这个就是基于JWT解决方案的单点登录解决方案；

​

应用和原理 : 什么是JWT，什么业务场景使用JWT？

JWT： http://jwt.io/

JSON Web Tokens are an open， industry standard RFC 7519 method for representing **claims** securely between two parties.

JSONWeb令牌是一种开放的、行业标准的RFC7519方法，用于在双方之间安全地表示**声明**。

JWT 应用场景：

Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用，JWT 省去了服务器存储用户信息的过程。

Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。

JWT的令牌结构 看官方文档https://jwt.io/introduction/ 并解释

JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：Header，Payload，Signature。

官网对于这个三部分的定义。一个典型的JWT Token是 tttttttt.yyyyyyyyyyy.eeeeeee 这样组成。

​

Header : 由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。然后，用Base64对这个JSON编码就得到JWT的第一部分。

Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。分为三种类型

1：registered claims。标准声明。一般常用于校验的有 iat，exp，nbf 校验 token 是否过期。

*/\**   
*iss: jwt签发者*   
*sub: jwt所面向的用户*   
*aud: 接收jwt的一方*   
*exp: jwt的过期时间，这个过期时间必须要大于签发时间*   
*nbf: 定义在什么时间之前，该jwt都是不可用的.*   
*iat: jwt的签发时间*   
*jti: jwt的唯一身份标识，主要用来作为一次性token，从而回避重放攻击*   
*\*/*

2：public claims。公开声明。 可以存放任意信息，比如userid等。不是信息安全的。

3：private claims。私密声明。 双方约定的信息。

Signature Base64(header).Base64(payload) + head中定义的算法 + 密钥 生成一个字符串 。

使用方式：

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

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

// Authorization: Bearer <token>

另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。

基于CAS同公司不同域的单点登录解决方案

Yelu大学研发的CAS单点登录原理:

​

主要步骤分为:

• 1、用户请求CAS Client的某一个网站，或者直接请求CAS Server登录页面；

• 2、用户到CAS Server的登录页面进行验证，验证成功，CAS Server返回ticket到客户端；

• 3、客户端再次请求CAS Client资源， CAS Client携带ticket到CAS Server认证，成功则继续访问；

实现步骤:

• 1、搭建CAS Server端，可使用CAS的框架实现；可自定义登录页面；实现其内部接口即可；

• 2、搭建CAS Client端，就是公司不同的服务器系统，携带秘钥即可；

基于Auth2.0之第三方登录

OAuth 2.0是用于授权的行业标准协议。
OAuth 2.0 is the industry-standard protocol for authorization。

OAuth定义了四个角色:

• 资源所有者
  能够授予对受保护资源的访问权限的实体。
  当资源所有者是一个人时，它被称为最终用户。

• 资源服务器
  托管受保护资源的服务器，能够接受并使用访问令牌响应受保护的资源请求。

• 客户
  代表受保护的资源请求的应用程序资源所有者及其授权。“客户”一词的确如此并不意味着任何特定的实施特征（例如，应用程序是在服务器，桌面还是其他服务器上执行设备）。

• 授权服务器
  服务器成功后向客户端发出访问令牌验证资源所有者并获得授权。

授权模式

• 1 简化模式（Implicit）

• 2 授权码模式（Authorization Code）

• 3 密码模式（Resource Owner Password Credentials Grant）

• 4 客户端模式（Client Credentials）

场景: 公司的网站支持第三方登录(qq登录，微信登录，微博登录):

qq开放平台:https://connect.qq.com/index.html

微博开放平台: https://open.weibo.com/authentication/

接入方式按照对应的平台操作即可，第三方网站接入文档提示非常全面.

关于登录，还需要关注分布式下登录成功以后，分布式Session的问题以及解决方案；

方案是用来解决问题的，这些方案没有好不好的说法，只有合不合适的说法，合适的才是最好的。

本文收藏来自互联网，仅用于学习研究，著作权归原作者所有，如有侵权请联系删除

markdown 9ong@TsingChan

部分引用格式为收藏注解，比如本句就是注解，非作者原文。