本文目录一览：
26.FastAPI安全性
软件开发中，安全是永恒的话题，FastAPI作为一个优秀的Python Web开发框架，为用户提供了多种工具，帮助用户以标准的方式轻松快速地解决软件开发中的安全性。
FastAPI 的 fastapi.security 模块中为各种安全方案提供了一些工具，这些工具简化了这些安全机制的使用方法。
FastAPI提供的OAuth2PasswordBearer是使用 OAuth2的密码授权模式的Bearer Token(不记名 token) 。创建OAuth2PasswordBearer 实例需要接收URL作为参数。
客户端会向该 URL 通过表单的格式发送 username 和 password 参数，然后得到一个 token 值；OAuth2PasswordBearer 并不会创建相应的 URL 路径操作，只是指明了客户端用来获取 token 的目标 URL。
代码示例：
在上面的代码中， tokenUrl="token"指的token是相对 URL 。
此时访问，其返回结果：
上面的结果表明：访问的内容以及被保护，必须经过授权后才可以访问。
当获取到表单数据后，需要进行密码校验，一般情况下，我们都会考虑使用哈希密码，PassLib 是一个用于处理哈希密码的非常好的 Python 包，它支持许多安全哈希算法以及配合算法使用的实用程序。
具体passlib的使用方法可以查看其文档
下面的代码示例在上面代码的基础上增加用户登录及Token验证
启动应用并执行请求：
测试无效登录：
测试正常登录：
返回token，在Headers中使用token访问：
修改token后请求：
上面的代码如果去掉 await verify_token(token) 行，则：
curl -H "Authorization:Bearer u000010007" -i
会得到返回结果，原因是默认情况下，OAuth2PasswordBearer只负责请求头中是否具有Authorization:Bearer，如果有就会执行相应的请求，所以，为了验证Token的正确性，需要每个方法都执行相应的验证代码。
本例只作为例子，在实际开发中不会直接拿用户ID作为Token，为了提高系统的安全性，需要使用 JWT。下面我们就介绍 JWT。
JWT是一个将 JSON 对象编码为密集且没有空格的长字符串的标准。 具体学习和了解 JWT，请参考 。
需要提到的主要是 JWT中的sub，JWT 的规范中有一个 sub 键，值为该令牌的主题。使用它并不是必须的，但这是我们放置用户标识的地方，所以一般情况下，我们在sub中存放用户ID， 为了避免 ID 冲突，当为创建 JWT 令牌时，可以在 sub 键的值前加上前缀，例如 username:、userid:等。
在 Python 中生成和校验 JWT 令牌 ，可以使用PyJWT，也可以使用 python-jose 。我们在本例中使用 python-jose 来编写代码。
使用：
使用 JWT，需要在系统中添加一个SECRET_KEY变量，用于生成令牌，如：
以下代码在上面代码的基础上使用 JWT 令牌。
与前面的代码差别之处：
1.生成Token的函数：build_access_token
2.校验Token的函数：verify_token
3.登录函数：login
请求测试：
登录：
令牌访问：
错误的令牌访问：
在大部分应用程序中，当用户访问某个接口API的时候，都需要明确访问者的身份，所以在应用程序中需要随时获取当前用户，由于在 JWT 令牌的 sub 字段中已经保存了用户信息，所以获取当前用户只需要对令牌解码即可。
在上面的代码的基础上，增加两个函数，代码如下：
请求测试：
以上，我们完成了一个简单的安全性示例，FastAPI提供的安全性框架帮助我们节约了很多代码，但在实际开发中，我们常常使用微服务的方式来开发，对于鉴权最好设计独立的微服务进行处理。后面我们会展示一个采用FastAPI开发的鉴权微服务，以便在此基础上进行业务系统的开发。
程序员应该如何设计更优雅的Token认证方式？
通过上一篇你大体已经了解session和cookie认证了，session认证需要服务端做大量的工作来保证session信息的一致性以及session的存储，所以现代的web应用在认证的解决方案上更倾向于客户端方向，cookie认证是基于客户端方式的，但是cookie缺点也很明显，到底有哪些缺点可以跳转上一次的文章。那有没有一种比较折中的方案呢？有的
把认证信息保存在客户端，关键点就是安全的验证，如果能解决认证信息的安全性问题，完全可以把认证信息保存在客户端，服务端完全无认证状态，这样的话服务端扩展起来要方便很多。关于信息的安全解决方案，现在普遍的做法就是签名机制，像微信公众接口的验证方式就基于签名机制。
当用户成功登陆系统并成功验证有效之后，服务器会利用某种机制产生一个token字符串，这个token中可以包含很多信息，例如来源IP，过期时间，用户信息等， 把这个字符串下发给客户端，客户端在之后的每次请求中都携带着这个token，携带方式其实很自由，无论是cookie方式还是其他方式都可以，但是必须和服务端协商一致才可以。当然这里我不推荐cookie。当服务端收到请求，取出token进行验证（可以验证来源ip，过期时间等信息），如果合法则允许进行操作。
基于token的验证方式也是现代互联网普通使用的认证方式，那它有什么优点吗？
1. 支持跨域访问，Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
2. 无状态:Token机制在服务端不需要存储session信息，因为Token自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
3. 解耦 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
4. 适用性更广：只要是支持http协议的客户端，就可以使用token认证。
5. 服务端只需要验证token的安全，不必再去获取登录用户信息，因为用户的登录信息已经在token信息中。
6. 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python,PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.
那基于token的认证方式有哪些缺点呢？
1. 网络传输的数据量增大：由于token中存储了大量的用户和安全相关的信息，所以比单纯的cookie信息要大很多，传输过程中需要消耗更多流量，占用更多带宽，
2. 和所有的客户端认证方式一样，如果想要在服务端控制token的注销有难度，而且也很难解决客户端的劫持问题。
3. 由于token信息在服务端增加了一次验证数据完整性的操作，所以比session的认证方式增加了cpu的开销。
但是整体来看，基于token的认证方式还是比session和cookie方式要有很大优势。在所知的token认证中，jwt是一种优秀的解决方案
一个JWT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。
header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。
Payload 部分也是一个JSON对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。
除了以上字段之外，你完全可以添加自己想要的任何字段，这里还是提醒一下，由于jwt的标准，信息是不加密的，所以一些敏感信息最好不要添加到json里面
为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥（这个秘钥只有服务端知道），签名算法是header中指定的那个，然对它们签名即可。
算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。需要提醒一下：base64是一种编码方式，并非加密方式。
基于token的认证方式，大体流程为：
这里再重复一次，无论是token认证，cookie认证，还是session认证，一旦别人拿到客户端的标识，还是可以伪造操作。所以采用任何一种认证方式的时候请考虑加入来源ip或者白名单，过期时间，另外有条件的情况下一定要使用https。
python jwt 加密为很么不行，大神帮忙瞧瞧
private_key = b'-----BEGIN PRIVATE KEY-----\nMIGEAgEAMBAGByqGSM49AgEGBS...'
'-----BEGIN PRIVATE KEY-----\n'这后面的数据每64个字符加个\n分割一下试试
