访问控制
API Keys
API Keys是一种用于标识和验证请求API服务的应用程序或用户的一串字符
原理
原理简单, 调用 api 的时候携带的一串无标准定义的子串, 形式格式随开发人员随心所欲
本质上可以作为 token, password, access_code 等方式, 使用方面主打一个自由自在, 无标准无定义
其性能和安全性则也是因人而异
适用场景
较为简单的场景. 在不考虑稳定性安全性的内网场景下比如设置无限制内部凭证等情况下适用较多
一般主要用于快捷开发, demo, 脚本对接, sdk 等场景, 或者对接api场景下比如一系列开放平台
如 Google Maps, 微信公众平台, 阿里云开发者社区等
SAML
原理
性能
拓展
安全
场景
JWT
JWT (JSON Web Token) 基于2015年5月发布开放标准（RFC 7519）的认证协议，以紧凑自包含的形式提供给两方安全的信息传输
可使用 HMAC算法 或 RSA的公钥/私钥对 进行数字签名，确保仅发送者可以生成签名，且验证消息的完整性合法性
原理
JWT由三部分组成：Header(头部), Payload(有效负载) 和 Signature(签名)
Header（头部） 通常由两部分组成：token的类型（即JWT）和使用的签名算法（例如HMAC SHA256或RSA）
Payload（有效负载） 包含“声明”，声明是关于实体（通常是用户）和其他数据的陈述
Signature（签名） 为了创建签名部分，你必须采用编码后的header和payload，使用header中指定的算法和密钥进行签名
性能
JWT是非常轻量的微短信息，所以它们在网络上的传输很快，并不会引入太多的额外延迟
由于它们是自包含的，服务器不需要查询数据库来验证token, 在IO密集场景具备优势
但是在高密集请求的场景下, 频繁的解密过程对于系统计算资源占用则会引入一些性能开销, 尤其是 RSA 这种复杂算法
拓展
由于JWT不需要服务器维护客户端的状态，因此它促进了无状态的设计，这可以简化服务器的性能扩展
但是在token信息需要更新（如用户权限变更），需要废止现有token并重新发放新的token
安全
JWT的安全性依赖于签名和加密的实施, 在安全性方面的亦可改进和注意的部分如下
1. 可采用更强加密算法（如 RSA 而不是 HS256）
2. 二次加密重要数据，以防止其被Payload中的信息泄露
3. 使用HTTPS协议来避免token被拦截
4. 设置合理的过期时间，以减少由于token泄露带来的风险
5. 验证服务的安全性和JWT实现的漏洞
场景
SSO 单点登录, 微服务架构, 分布式系统
缺陷
-
令牌包含内容过多导致长度较长时，会增加网络传输开销
-
令牌一旦签发，无法撤销，只能等待过期，增加安全风险
-
令牌中的数据可能被解密，需要注意敏感信息的保护
Oauth2
OAuth 2.0 基于2012年的开放标准 (RFC 6749) 协定授权框架，即一系列的流程规范
允许第三方应用程序在用户的授权下，通过API安全地获取对用户在HTTP服务上的资源的访问权限
原理
OAuth 2.0的原理是通过访问令牌（Access Token）和授权代码（Authorization Code）来实现授权流程。
Access Token 访问令牌是客户端用来访问资源服务器上受保护资源的凭证
Authorization Code 授权代码是客户端向授权服务器请求访问令牌的中间凭证
授权流程由以下四种, 可满足丰富的场景需求
-
授权码（Authorization Code）
-
简化（Implicit）
-
资源所有者密码凭证（Resource Owner Password Credentials）
-
客户端凭证（Client Credentials）
以授权码流程为例，整个流程包括以下步骤：
（A）用户打开客户端以后，客户端要求用户给予授权（B）用户同意给予客户端授权
（C）客户端使用上一步获得的授权，向认证服务器申请令牌
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌
（E）客户端使用令牌，向资源服务器申请获取资源
（F）资源服务器确认令牌无误，同意向客户端开放资源
性能
OAuth 2.0 作为流程规范, 本身没有对校验串进行相应得计算加解密操作, 因此对计算资源无额外负担
令牌持有机制也保证了后续得查询无需频繁的校验, 但是应对高频请求得场景下, 其主要受限于服务器性能和网络延迟和带宽
拓展
OAuth 2.0的拓展性很强，可以根据不同的需求进行定制和扩展。
-
支持多种类型的客户端，如Web应用、移动应用、桌面应用等
-
支持多种类型的资源，如API、文件、照片等
-
支持多种类型的授权范围，如读、写、删除等
-
支持多种类型的身份验证方式，如静态密码、手机验证码、生物识别等
安全
OAuth 2.0通过访问令牌提供了额外的安全性，因此客户端不需要存储用户的用户名和密码, OAuth 2.0的安全性主要依赖于正确的实现和使用
如果不遵循OAuth 2.0的安全指导，可能会导致一些安全风险，如重定向域名欺骗、跨站脚本攻击、跨站请求伪造、访问令牌泄露等
为了保证OAuth 2.0的安全性，需要注意以下几点：
-
服务端必须验证客户端标识和重定向地址是否匹配，防止重定向域名欺骗
-
服务端必须对重定向地址进行检查，防止跨站脚本攻击
-
客户端必须使用state参数，防止跨站请求伪造
-
客户端和服务端必须使用HTTPS协议，防止访问令牌泄露
-
客户端必须妥善保管访问令牌和刷新令牌，防止被盗用或滥用
-
服务端必须限制访问令牌的有效期和作用域，防止过度授权或长期授权
场景
-
社交登录 用户可以使用他们的社交媒体帐户登录到其他应用程序，例如使用Google或Facebook登录
-
API访问 开发人员可以使用OAuth 2.0来访问第三方API，例如使用GitHub API或Twitter API等各类开放平台
-
单点登录 用户可以使用一个身份验证提供商登录到多个相关的应用程序，而无需多次输入凭证
-
授权访问 应用程序可以请求用户授权访问其资源
-
移动应用授权 移动应用程序可以安全地请求访问用户数据，如照片、联系人或位置信息
缺陷
-
复杂 需要理解和实现多个角色、终端、流程和参数
-
易错 需要遵循OAuth2的安全指导，防止重定向欺骗、跨站攻击、令牌泄露等
-
依赖 需要依赖认证服务器和资源服务器的性能和可用性