聊聊登录认证这件事

这里介绍的是减少登录页面的编写的方法，比如一个公司中有A，B, C 三个系统，对于用户来说希望是我只需要登录（认证）一次就可以访问A，B，C三个系统，而不是进到A系统在A中登录（认证）一次，进到B系统又要在B中登录（认证）一次，进到C系统还要在C中登录（认证）一次，这样一方面会有重复的编码（A，B，C系统的登录页面逻辑），另一方面对用户来说也是非常不友好。

请区别于对系统中的资源的权限校验

关于LDAP

轻量级目录访问协议 (LDAP) 是一种使应用程序可以快速查询用户信息的协议。

“什么是目录服务？”

  • 目录服务是一个特殊的数据库，用来保存描述性的、基于属性的详细信息，支持过滤功能。
  • 是动态的，灵活的，易扩展的。

如：人员组织管理，电话簿，地址簿。

LDAP介绍

  • LDAP（Light Directory Access Portocol），它是基于 X.500 标准的轻量级目录访问协议。
  • 目录是一个为查询、浏览和搜索而优化的数据库，它成树状结构组织数据，类似文件目录一样。
  • 目录数据库和关系数据库不同，它有优异的读性能，但写性能差，并且没有事务处理、回滚等复杂功能，不适于存储修改频繁的数据。所以目录天生是用来查询的，就好象它的名字一样。

LDAP目录服务是由目录数据库和一套访问协议组成的系统。

LDAP 登录流程

image-20220313130546204

单点登录(SingleSign-On，SSO)

单点登录 (SSO) 是一种身份验证方法，可让用户仅使用一组凭据即可安全地对多个应用程序和网站进行身份验证

SSO的想法就是将身份提供者（Identity provider，IDP），**服务提供者（Service provider，SP）**彻底分离，用户用IDP提供的身份就可以在Web世界畅通无阻。

这里面最让人头疼的其实是安全问题。如何保证用户的身份在逻辑上不能被冒充，才是最难的题目。数据加密，**数字签名（Digital Signature）**等各种密码学知识刚好解决了这个问题。

在2001年由OASIS组织安全服务技术委员会(Security Services Technical Committee)推出了**SAML（安全主张标记语言，Security Assertion Markup Language），**就是提出了对SSO实现的整体技术和安全规范。

SAML是以XML为基础，不用JSON的原因，大概是因为JSON一直在1999年才发明，2004年以后才流行起来逐渐取代了XML。在这之前，XML一直是作为网络通讯的标准格式。

在SAML协议中，实际上也包含了可以发送账号属性等登陆外的扩展部分。SAML协议实际内容很多，就不一一介绍，这里只围绕单点登录来说明。

SAML协议里，约定了参与SSO的三方：浏览器，身份提供者（IDP），服务提供者（SP），以及这三方相互的通讯次序，加密方法，传输数据格式。

image-20220313130627731

LDAP 和 SSO 对比

  • LDAP协议里只负责用户身份的认证，不包含授权过程。在SAML协议中，不仅包含身份认证，还包含是否允许用户访问当前网站内容的授权部分。
  • LDAP服务与应用之间是毫无条件的充分信任，LDAP几乎是作为应用的远程数据库一般的存在。而在SAML中，SP与IDP不仅需要在事前互相信任（互换签名公钥与IP地址），还要在认证过程中防止他人伪造而进行数据校验。因为SAML定义的SP与IDP是在互联网上相互独立的站点。
  • 同时能注意到SAML协议非常依赖浏览器重定向功能，而LDAP协议都是应用与LDAP服务间的直接通讯。
    • 浏览器重定向，其实就是指当前你访问的页面主动跳转到另外一个网站的网页上去，在跳转的过程中可以给这次访问网页的请求上附加上一些数据用来完成数据传输。

OpenID诞生

一个叫布莱德的程序员在1999年的时候，开发了一个类似博客一样的社区网站。运营的还不错，有了好几百万用户。你看，互联网公司，几百万用户，感觉可以开始做自己的SSO登录了。可这次布莱德不想做一个跟巨头们一样的东西，毕竟就算做出来估计也打不过。那要不要尝试去中心化的路子？

中心化

去中心化这个概念随着比特币流行而火爆了起来，其实去中心化这个概念很早就有了。

  • 中心化的意思就是用户在使用某项服务时，所有的访问请求都需要向同一个主体的服务器地址发送。比如每个微信用户的客户端，都是在跟腾讯公司的服务端交流，A发送给B一条消息，都是A先发送给腾讯服务端，再由腾讯服务端转发给B。A是不能通过其它公司或个人的服务端发送给B消息的。

类似这样，所有用户都围着中间一个服务端，就管这种叫中心化的服务。

去中心化

  • 就是并没有固定的一个服务商提供服务，任何人只要他愿意的话，都可以作为服务端来给用户服务，用户也可以自由的切换服务端。这种方式显然是不符合已经拥有大量用户的互联网公司的利益，但却迎合了用户和中小企业抱团取暖的需求。

于是布莱德在2005开始了一个叫OpenID的项目开发，这个项目在软件社区中得到了响应，越来越多的人参与进来，之后越来越多的人开始使用。OpenID的目的就是建立一个统一的SSO的方式，而不用在意IDP服务的提供方。用户完全可以自己启动一个IDP的服务，或者选择一个用户信任的IDP服务提供方，在这个IDP服务上完成注册。那么只要SP站点能使用OpenID的方式，用户就可以完成登录了。

OpenID登录流程

image-20220313130724620

常见的两种登录框架

OAuth 2.0 定义了一个协议，即规定了token 的传输方式，JWT 定义了一种token 格式

CAS（Central Authentication Service）

CAS框架：CAS（Central Authentication Service，即：统一认证服务）是实现SSO单点登录的框架。

img

OAuth 2.0

OAuth2是当前授权的行业标准，其重点在于为Web应用程序、桌面应用程序、移动设备以及室内设备的授权流程提供简单的客户端开发方式。它为第三方应用提供对HTTP服务的有限访问，既可以是资源拥有者通过授权允许第三方应用获取HTTP服务，也可以是第三方以自己的名义获取访问权限。

角色

OAuth2 中主要分为了4种角色

  • resource owner 资源所有者，是能够对受保护的资源授予访问权限的实体，可以是一个用户，这时会被称为end-user。
  • resource server 资源服务器，持有受保护的资源，允许持有访问令牌(access token)的请求访问受保护资源。
  • client 客户端，持有资源所有者的授权，代表资源所有者对受保护资源进行访问。
  • authorization server 授权服务器，对资源所有者的授权进行认证，成功后向客户端发送访问令牌。

协议流程

首先看一张来自官方提供的流程图：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

 +--------+                               +---------------+
 |        |--(1)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(2)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(3)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(4)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(5)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(6)--- Protected Resource ---|               |
 +--------+                               +---------------+

这是一张关于 OAuth2 角色的抽象交互流程图，主要包含以下的6个步骤：

  1. 客户端请求资源所有者的授权；
  2. 资源所有者同意授权，返回授权许可(Authorization Grant)，这代表了资源所有者的授权凭证；
  3. 客户端携带授权许可要求授权服务器进行认证，请求访问令牌；
  4. 授权服务器对客户端进行身份验证，并认证授权许可，如果有效，返回访问令牌；
  5. 客户端携带访问许可向资源服务器请求受保护资源的访问；
  6. 资源服务器验证访问令牌，如果有效，接受访问请求，返回受保护资源。 客户端授权类型

参考文章