我正在构建移动后端服务。我想知道，想象一下像认证服务这样的服务为购买一堆服务（逻辑上称为应用程序）的人提供了应用程序密钥广告应用程序秘密。
假设有服务X，Y，Z等，还有AuthService。
假设应用中没有“用户”的概念， 我想我可以使用app key和app secret来限制服务的API访问。
但是，
由于我无法在本地验证(appkey , appsecret)，因为它与(username , password)一样好，我必须进行AuthService服务调用以查明API调用是否有效。但这会影响性能，因为每次调用服务X实际上都是两个服务调用。
我的问题： 通常，应用程序是否经过验证？ 为什么要使用appkey和appsecret？ 为什么没有来自应用程序的 “app token” ，这是自给自足的，我不必进行AuthService调用。您可以随时使用Https并避开中间人，并让SDK安全地存储应用令牌。
我听说过在X，Y，Z等服务中缓存应用信息（app-token）并在本地验证的解决方案。但是一旦你掌握了我的app密钥和秘密，无论我在哪里存储它，你都可以聚会，而且个人服务中的缓存也是多余的。您最终还会在缓存中存储授权信息，这些信息可能会快速更改。缓存失效可能是个问题。 ？
请帮忙， 提前谢谢。
答案 0 :(得分：0)
我会一个接一个地按顺序回答你的问题
<强> 1。缓存appid和appkey
这里的appKey就像一个密码，appId就是一个用户名。您不会保存密码，因为它在数据库中。我将使用salt进行哈希处理，然后将其保存到数据库中。因为我们知道散列是一种方式，即使黑客能够访问数据库，他也无法获得用户的密码。
2.每次都停用Auth服务器
不是每次都调用auth服务器，而是生成一个时间限制令牌，该令牌将在指定时间内使用，一旦令牌过期，您可以生成新令牌或提高现有令牌的有效性。您可以缓存此令牌而不是缓存appKey。
注意：如果有足够的资源和足够的时间，任何密码都可以破解。资源和时间的成本可能非常巨大
答案 1 :(得分：0)
所描述的方案看起来像是使用OAuth 2.0进行self-contained bearer access tokens授权的经典案例。
将对客户端进行身份验证，并在OAuth 2.0授权和/或令牌端点上发出访问令牌。访问令牌可以由签名JWT表示，该签名{{3}}对使用OAuth 2.0服务器的RSA密钥签名的JSON对象中的权限范围和有效性时间帧进行编码。 X，Y和Z服务只需在收到JWT访问令牌时检查签名即可清除请求。这将节省对auth服务的网络调用，并且可以在大约100微秒内完成RSA签名检查，这比HTTP请求（大约几十或更多毫秒）要少得多。