因此,我不确定我的问题是否符合堆栈溢出,但我会尝试一下,看看我对JWT的了解是否真的正确,还是完全超出了循环的范围。
因此,我创建了一个服务器API,它读取从客户端应用程序发送的POST请求,并返回Bearer令牌,这是访问我创建的API的其余部分所必需的。
到目前为止,我有一个服务器api,如果用户名和密码与登录名匹配,它就会创建Bearer令牌。
一个简单的POST请求看起来就像
{'username': 'hello', 'password': 'world'}因此,我所做的是用一个秘密代码创建了一个从JWT.IO站点编码的JWT,如下所示:
{'username': 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImJhcnJ5In0.-TCwkrPr8dq4WqsckaWNG7G2ddn7e97hH0jkQ-1j5Bo',
 'password': 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXNzd29yZCI6ImF1dG9zbmtyIn0.mWvxW4xga_OQMLKxf5zfSP4bSV0KzLPSRpqapU-RbAw'}但是,我的主要问题是,我应该如何处理客户端应用程序->第一个/token请求之间的连接,以便能够获得承载令牌?
似乎我确实需要在客户端应用程序中“硬编码”用户名和密码才能访问我的api,但我觉得这不是正确的方法,因为这样您就可以读取网络日志并向服务器发送相同的请求,您将永远得到一个新的Bearer令牌,您可以操纵我的服务器API。
我的问题是,我应该怎么做才能不能够在客户端应用程序中公开我的用户名和密码,并且能够通过我的服务器api进行操作?因为我的服务器所做的是用机密从JWT中解码用户名和密码,并匹配用户名和密码是否与我的服务器api用户名和密码匹配。但是,如果用已经完成编码的JWT令牌公开我的用户名和密码,您仍然可以使用这些值并做任何您想做的事情?
客户端应用程序示例:
import requests
headers = {
    'accept': 'application/json',
    'Content-Type': 'application/x-www-form-urlencoded',
}
data = {'username': 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImJhcnJ5In0.-TCwkrPr8dq4WqsckaWNG7G2ddn7e97hH0jkQ-1j5Bo',
        'password': 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXNzd29yZCI6ImF1dG9zbmtyIn0.mWvxW4xga_OQMLKxf5zfSP4bSV0KzLPSRpqapU-RbAw'}
response = requests.post('http://127.0.0.1:8000/token', headers=headers, data=data, verify=False)发布于 2019-12-21 02:04:17
从您的描述来看,您用例中的客户端似乎是代表自己而不是代表人类用户。
在这种情况下,适用的OAuth2授予类型称为“客户端凭据”,其中客户端在“授权”头中向授权服务器发送客户凭据(通常是客户端id和客户端机密)。然后,授权服务器将共享一个访问令牌和/或刷新令牌,这些令牌需要存储在cookie中(通常以JWT的形式),并与每个后续请求一起发送到资源服务器。“授权”头唯一的特别之处在于它告诉整个HTTP次席结构不要在任何共享缓存中缓存值。
现在,问题是,我们如何存储客户的秘密。我们应该在客户端硬编码吗?哪儿有的事儿。当然不是。通常,最安全的处理方法是将其存储在密码库中。通常,金库将秘密、密码和证书存储在防篡改硬件安全模块(HSM)中。(但在没有保险库的情况下,将秘密以加密形式存储在单独的文件中也是常见的做法)。
唯一要回答的问题是,客户是如何连接到地下室的。Vault信任平台(比如AWS或Kubernetes或任何其他云平台)。当VM或容器在这些平台中启动时,容器中的平台会注入令牌。然后,应用程序将使用令牌连接Vault,从而验证令牌与平台的真实性。
https://stackoverflow.com/questions/59408029
复制相似问题