认证
认证是指验证实体（如用户、设备）的身份是否真实和有效。认证通常要求提供凭据（如用户名和密码）或使用其他身份验证方（如生物特征识别）。所以我理解 认证 就是 认识并证明 某人是某人，使其能够表明自己的身份。
常用的认证手段
- 用户名和密码认证：用户提供预先注册的用户名和对应的密码进行身份验证。
- 双因素认证：用户需要提供两种或多种不同类型的凭据，如密码和手机验证码、指纹扫描等，以增加身份验证的安全性。
- 生物特征认证：使用个体的生物特征信息，如指纹、面部识别、虹膜扫描等来验证身份。
- 证书认证：基于数字证书进行身份验证，使用公钥和私钥来确保身份的真实性和完整性。
授权
授权是指授予用户或实体特定权限或访问权限。授权机制可以确保用户只能访问其被授权的资源，从而保护系统的安全性和完整性。所以我理解 授权就是 授予 某人 某种权限，使其能够获得对应的资源。
常用的认证方式
- 访问控制列表（ACL）：ACL是一种基于资源的授权技术，通过定义资源的访问控制列表，指定哪些用户或组可以访问该资源。
- 角色基础访问控制（RBAC）：RBAC是一种授权模型，将权限授予特定的角色，然后将角色分配给用户，以实现对资源的授权。
- 属性基础访问控制（ABAC）：ABAC是一种基于属性的授权技术，根据用户的属性和环境条件，动态决定其对资源的访问权限。
- 强制访问控制（MAC）：基于系统定义的安全策略，授予用户对资源的访问权限。
访问控制列表（ACL） 和 角色基础访问控制（RBAC）有什么区别
-
RBAC（角色基础访问控制）：RBAC是一种基于角色的访问控制模型。它将权限授予特定的角色，而不是直接授予用户。用户通过被分配到适当的角色来获得相应的权限。RBAC可以简化权限管理，特别是在大型组织或系统中，因为权限的管理集中在角色上，而不是每个用户上。例如，一个系统可能有管理员角色、编辑角色和普通用户角色，每个角色都有不同的权限级别。
-
ACL（访问控制列表）：ACL是一种基于资源的访问控制模型。它使用列表来定义哪些用户或组可以访问特定的资源。每个资源都有一个关联的ACL，其中包含了被授权用户或组的列表。ACL可以精确地控制每个用户对资源的访问权限。例如，一个文件系统可以为每个文件或目录定义一个ACL，确定哪些用户可以读取、写入或执行该文件或目录。
总的来说，RBAC更适合在大型组织或系统中管理复杂的权限结构，通过角色的方式来授予用户权限。而ACL更适合对于每个资源进行细粒度的权限控制，可以更精确地控制用户对特定资源的访问权限。具体使用哪种访问控制机制，取决于应用的需求和安全策略。
接下来要说的这俩货 SSO（单点登录） 和 OAuth（开放授权） 我认为及涉及到了 认证 也涉及到了 鉴权
SSO（单点登录）
维基百科的解释
单点登录（英语：Single sign-on，缩写为 SSO），又译为单一签入，一种对于许多相互关连，但是又是各自独立的软件系统，提供访问控制的属性。当拥有这项属性时，当用户登录时，就可以获取所有系统的访问权限，不用对每个单一系统都逐一登录。这项功能通常是以轻型目录访问协议（LDAP）来实现，在服务器上会将用户信息存储到LDAP数据库中。相同的，单一退出（single sign-off）就是指，只需要单一的退出动作，就可以结束对于多个系统的访问权限。
百度百科
单点登录(SingleSignOn，SSO)，就是通过用户的一次性鉴别登录。当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。这种方式减少了由登录产生的时间消耗，辅助了用户管理，是比较流行的。
看样子 SSO 更关注的是 用户登录问题，登录就会涉及到 用户、密码 啊啥的，所以 SSO 更像是一种认证技术，但是从另一个角度来看看，是不是可以理解为 某种机制或者某个东西授权了你可以在它认为可信的系统中来回穿梭呢，这不就是授权么。所以这里我也不再纠结了。
- 基于令牌的SSO：用户在完成认证后，SSO系统会颁发一个令牌（如JSON Web Token）给用户，该令牌包含用户身份信息和访问权限。用户在访问其他应用程序时，将令牌传递给应用程序进行验证，从而实现单点登录。
- 基于SAML的SSO：SAML（Security Assertion Markup Language）是一种基于XML的开放标准，用于在不同的身份提供者和服务提供者之间进行身份认证和授权。用户通过SSO系统进行认证后，SSO系统会向应用程序发送SAML断言，证明用户的身份和权限。
- OAuth和OpenID Connect：OAuth和OpenID Connect是一种常见的SSO实现方式，特别适用于第三方应用程序集成。用户通过授权服务器进行认证，并获得访问令牌。应用程序可以使用该令牌进行用户身份验证和访问授权。
- 集中式认证和授权系统：通过建立一个集中式的认证和授权系统，所有应用程序都与该系统进行集成。用户在认证系统中进行一次登录后，系统会为其颁发令牌，并将令牌传递给其他应用程序进行验证。
上面第三点说到了 OAuth. 你可能会好奇 这玩意不是用来授权的么，怎么跟认证又有关系了呢？因为这里登录的时候认证方式用的是授权的形式，只要第三放应用授权了，你的网站就默认登录了。所以也不必纠结到底该算授权呢还是概算认证呢。认证之后紧跟着就该是鉴权了(鉴权之前得先授权吧)。
OAuth（开放授权）
OAuth（开放授权）是一种开放标准的授权协议，用于授权用户访问第三方应用程序或服务的受保护资源，而无需共享其凭据（如用户名和密码）。OAuth通过颁发访问令牌（Access Token）来实现授权，该令牌用于代表用户向资源服务器请求访问。OAuth适用于用户允许第三方应用程序访问其受保护资源的场景，同时保护用户的凭据安全。
所以，OAuth 的终极目标是为了隐藏凭据，也就是账号密码。
OAuth现在以OAuth2为主,有以下几种模式
1. 授权码模式（Authorization Code Grant）：在这种模式下，用户在客户端应用程序中发起授权请求，被重定向到授权服务器进行身份验证。一旦用户授权，授权服务器将返回一个授权码给客户端应用程序，然后客户端应用程序使用该授权码与授权服务器进行交换，以获取访问令牌和刷新令牌。
- 优点：安全性高，授权码只在后端服务器之间传输，避免了敏感信息在浏览器中的传输。支持刷新令牌，可实现长期访问。
- 缺点：实现复杂，涉及多个步骤和交互。需要维护客户端的机密性。
适用场景：适用于具有后端服务器的应用程序，需要高度安全性和长期访问的情况。
2. 简化模式（Implicit Grant）：这种模式适用于无法保持客户端应用程序的机密性的情况，如前端JavaScript应用程序。用户在客户端应用程序中发起授权请求，被重定向到授权服务器进行身份验证。一旦用户授权，授权服务器将直接返回访问令牌给客户端应用程序，不再返回授权码。
- 优点：简化了授权过程，减少了交互步骤。适用于前端JavaScript应用程序等无法保持机密性的情况。
- 缺点：访问令牌直接暴露在浏览器中，安全性较低。不支持刷新令牌，访问令牌的有效期较短。
适用场景：适用于无法保持机密性的前端应用程序，对安全性要求较低且访问令牌有效期较短的情况。
3. 密码模式（Resource Owner Password Credentials Grant）：在这种模式下，用户直接向客户端应用程序提供其用户名和密码。客户端应用程序使用这些凭据与授权服务器进行交换，以获取访问令牌和刷新令牌。这种模式需要用户将凭据直接提供给客户端应用程序，因此应谨慎使用。
- 优点：简化了授权过程，无需重定向到授权服务器。适用于信任度高、对安全性要求较低的情况。
- 缺点：需要用户直接提供用户名和密码给客户端应用程序，安全性较低。不适用于对用户隐私敏感的场景。
适用场景：适用于内部应用程序或高度信任的环境，对安全性要求较低且用户隐私不敏感的情况。
4. 客户端模式（Client Credentials Grant）：这种模式适用于客户端应用程序自身作为资源所有者的情况，而不是代表特定用户。客户端应用程序使用其自己的凭据与授权服务器进行交换，以获取访问令牌。
- 优点：简单直接，适用于客户端自身作为资源所有者的情况。无需用户参与，适用于后台任务或服务间的授权。
- 缺点：无法代表特定用户，适用范围有限。
适用场景：适用于客户端自身作为资源所有者的情况，例如后台任务或服务间的授权。
