认证

当企业的应用系统逐渐增多后，每个系统单独管理各自的用户数据容易行成信息孤岛，分散的用户管理模式阻碍了企业应用向平台化演进。当企业的互联网业务发展到一定规模，构建统一的标准化账户管理体系将是必不可少的，因为它是企业互联网云平台的重要基础设施，能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力，为企业带来诸如跨系统单点登录、第三方授权登录等基础能力，为构建开放平台和业务生态提供了必要条件。

多因子

sso

SSO系统是单独部署的一套认证系统，独立于所有子系统，包含登录认证、授权、用户管理功能。用户需要登录任意业务子系统时，都被重定向到认证中心，通过认证中心登录认证后，就会设置一个全局会话并重定向到子系统。子系统与验证中心通信验证Ticket的真伪，如果Ticket为真则将受保护资源返回给用户。

cas

CAS是一种仅用于Authentication的服务，它和OAuth/OIDC协议不一样，并不能作为一种Authorization的协议。当前CAS协议包括CAS 1.0、CAS2.0、CAS3.0版本，这三个版本的认证流程基本类似。CAS的认证流程通过包括几部分参与者:

• Client: 通常为使用浏览器的用户
• CAS Client: 实现CAS协议的Web应用
• CAS Server: 作为统一认证的CAS服务器

https://juejin.cn/post/7086098654565515300

OAuth2

OAuth2.0涉及到的几个对象

Client 第三方应用，比如微信小程序

Resource Owner 资源所有者，即用户

Authorization Server 授权服务器，即提供第三方登录服务的服务器

Resource Server 拥有资源信息的服务器，通常和授权服务器属于同一应用

OAuth2.0有五种授权模式。

（1）授权码模式（Authorization Code）

（2）授权码简化模式（Implicit）

（3）Pwd模式（Resource Owner Password Credentials）

（4）Client模式（Client Credentials）

但不论哪种模式，都是为了从认证服务器获取Access Token，用来访问资源服务器。

而申请Access Token，需要提交相应信息。例如，client_ID(我是谁)，response_type或grant_type(申请哪种模式)，scope(申请哪些权限，由授权服务器定义)，redirect_uri(申请结果跳转至哪儿),state(自定义信息希望服务端原样返回)等。当然不同的模式，提交信息内容也不同，交互的步骤也不同。

https://www.freebuf.com/articles/web/253170.html

https://www.freebuf.com/articles/web/283622.html

saml

SAML是一种XML框架用来交换安全信息，其中定义了按照安全规范所需要的通信的协议和格式。

SAML是一种中心化的认证机制，其定义了两种实体相互通信：

* Service Provider(SP): 向用户提供正式商业服务的实体，通常需要认证一个用户的身份（比如本次开发服务的员工管理系统，财务报销系统等）；
* Identity Provider(IDP): 提供用户的身份鉴别方，用以确保用户是其所声明的身份（比如本次公司提供统一登录的sso方）；

SAML的重要用途：

* 单点登录（SSO Single Sign-ON）；
* 联合认证（Federated Identity）；
* 在其他架构内使用SAML，比如WS-Security；

SAML在单点登录中大有用处：在SAML协议中，一旦用户身份被主网站IDP认证过后，该用户再去访问其他在主站注册过的应用SP时，都可以直接登录，而不用再输入身份和口令。

https://www.freebuf.com/articles/web/258028.html

https://www.freebuf.com/vuls/323321.html

OpenID Connect（OIDC）

正如我们所知，OAuth 解决了代理授权的问题，但是它没有提供一个认证用户身份的标准方法。你可以这样认为：

• OAuth2.0 用于授权
• OpenID Connect 用于认证

如果你无法区分这些术语，则以下是它们之间的区别：

• 认证（Authentication）是确保通信实体是其所声称的实体。
• 授权（Authorization）是验证通信实体是否有权访问资源的过程。

换言之，认证关注的是你是谁，授权关注的是你有什么权限。

OpenID Connect 是在 OAuth2.0 协议之上的标识层。它拓展了 OAuth2.0，使得认证方式标准化。

客户端发起的用于 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

ID 令牌是 JWT，或者又称 JSON Web Token。JWT 是一个编码令牌，它由三部分组成：头部，有效负载和签名。在获得了 ID 令牌后，客户端可以将其解码，并且得到被编码在有效负载中的用户信息，如以下例子所示：

{
  "iss": "https://accounts.google.com",
  "sub": "10965150351106250715113082368",
  "email": "johndoe@example.com",
  "iat": 1516239022,
  "exp": 1516242922
}

ID 令牌的有效负载包括了一些被称作声明的域。基本的声明有：

• iss：令牌发布者
• sub：用户的唯一标识符
• email：用户的邮箱
• iat：用 Unix 时间表示的令牌发布时间
• exp：Unix 时间表示的令牌到期时间

然而，声明不仅限于上述这些域。由授权服务器对声明进行编码。客户端可以用这些信息来认证用户。

如果客户端需要更多的用户信息，客户端可以指定标准的 OpenID Connect 范围，来告知授权服务端将所需信息包括在 ID 令牌的有效负载中。这些范围包括个人主页（profile）、邮箱（email）、地址（address）和电话（phone）。

Webauthn

WebAuthn用公钥证书代替了密码，完成用户的注册和身份认证（登录）。它更像是现有身份认证的增强或补充。为了保证通信数据安全，一般基于HTTPS（TLS）通信。在这个过程中，有4个模块。

Server（服务端）：

它可以被认为一个依赖方（Relying Party），它会存储用户的公钥并负责用户的注册、认证。

JavaScript（Js脚本）：

调用浏览器API，与Server进行通信，发起注册或认证过程。

Browser（浏览器）：

需要包含WebAuthn的Credential Management API提供给js调用，还需要实现与认证模块进行通信，由浏览器统一封装硬件设备的交互。

Authenticator（认证模块）：

它能够创建、存储、检索身份凭证。它一般是个硬件设备（智能卡、USB，NFC等），也可能已经集成到了你的操作系统（比如Windows Hello，MacOS的Touch ID等）

Webauthn提供了一个安全的无密码认证标准，彻底抛弃了密码，并且统一由操作系统完成安全硬件设备和生物特征识别的集成及管理，浏览器调用操作系统进行提供的能力形成认证器，应用开发者按标准与浏览集成即可完成FIDO认证，无需关心硬件设备的兼容和生物特征的算法，使得应用开发者集成FIDO认证抛弃密码更加容易和安全。

https://www.freebuf.com/articles/web/251848.html

jwt

JWT （ JSON Web Token 的缩写）是一串带有声明信息的字符串，由服务端用加密算法对信息签名来保证其完整性和不可伪造。Token里可以包含所有必要信息，这样服务端就无需保存任何关于用户或会话的信息，JWT可用于身份认证、会话状态维持、信息交换等。

JWT 由三部分构成，分别称为 header 、payload 和 signature ，各部分用. 相连构成一个完整的Token，形如xxxxx.yyyyy.zzzzz 。

https://www.freebuf.com/articles/others-articles/170359.html

https://www.freebuf.com/articles/web/337347.html

scram

SCRAM是密码学中的一种认证机制，全称Salted Challenge Response Authentication Mechanism。它适用于使用基于“用户名：密码”这种简单认证模型的连接协议。SCRAM是一个抽象的机制，在其设计中需要用到一个哈希函数，这个哈希函数是客户端和服务端协商好的，包含在具体的机制名称中。比如SCRAM-SHA1，使用SHA1作为其哈希函数。

SCRAM是一套包含服务器和客户端双向确认的用户认证体系，配合信道加密可以比较好的抵御中间人、拖库、伪造等攻击。信道应另外加密以增强安全性，如使用可靠TLS方法实现的HTTPS加密。

http://www.freeoa.net/scheme/manual/scram_3568.html

https://www.freebuf.com/vuls/212799.html

安全性分析

分析下以下几种情况下SCRAM的安全性：

网络流量被监听：如果某次认证的网络流量被监听，黑客可以拿到salt、iteration-count和Auth，但是无法伪装成服务端，因为没有key[s]，无法生成proof[s]，完成不了最后一次认证。

服务端被拖库：如果服务端被拖库，黑客可以拿到username、H(key[c])、key[s]、salt和iteration-count，但是生成不了key[c]，因此无法生成proof[c]，不能伪装成客户端。

如果很不幸的网络流量被监听，服务端又被拖库，那么对不起，要应对这种情况，只能使用信道加密了。

kerberos

由于 Kerberos 主要是用在域环境下的身份认证协议，所以在说之前先说下域环境的一些概念。首先域的产生是为了解决企业内部的资源管理问题，比如一个公司就可以在网络中建立一个域环境，更方便内部的资源管理。在一个域中有域控、域管理员、普通用户、主机等等各种资源。

在 Kerberos 认证中，最主要的问题是如何证明「你是你」的问题，如当一个 Client 去访问 Server 服务器上的某服务时，Server 如何判断 Client 是否有权限来访问自己主机上的服务，同时保证在这个过程中的通讯内容即使被拦截或篡改也不影响通讯的安全性，这正是 Kerberos 解决的问题。在域渗透过程中 Kerberos 协议的攻防也是很重要的存在。

https://www.freebuf.com/articles/network/273725.html

https://www.freebuf.com/articles/system/196434.html

搭建

https://www.cnblogs.com/yinzhengjie/p/10765503.html

NTLM

https://www.freebuf.com/articles/web/269876.html

在 Windows 中，最常见的两种认证体系便是 NTLM认证和 Kerberos认证了，

在 Windows 中是不会保存明文密码的，只会保存密码的哈希值。 其中本机用户的密码哈希是放在 本地的 SAM 文件 里面，域内用户的密码哈希是存在域控的 NTDS.dit 文件 里面。在渗透测试中，通常可从 Windows 系统中的 SAM 文件和域控的 NTDS.dit 文件中导出所有用户的Hash。

Windows 的 NTLM 认证就是利用 NTLM Hash 进行的认证，可以分为 本地认证 和 网络认证 两种方式。NTLM 的网络认证，既可用于域内的认证服务，又可用于工作组环境。NTLM 有 NTLMv1 、NTLMv2 、NTLMsession v2 三个版本，目前使用最多的是NTLMv2版本。