MBaaS 世界中 App Key 和 App Secret 的意义

Question

我正在构建移动后端服务。我在想，想象一下像 Authentication Service 这样的服务向购买一堆服务（逻辑上称为应用）的人提供 App key ad App secret。

假设有服务 X 、 Y 、 Z 等，还有一个 AuthService。

假设应用中没有“用户”的概念， 我想我可以通过使用应用密钥和应用机密来限制服务的 API 访问。

但是，

由于我无法在本地验证 (appkey , appsecret)，因为那里和 (username , password) 一样好，所以我必须进行 AuthService 服务调用来确定 API 调用是否有效。但这会影响性能，因为对服务 X 的每次调用实际上都是 两个 服务调用。

我的问题： 应用程序通常是否经过验证？ 为什么要使用 appkey 和 appsecret？ 为什么没有来自应用程序的 "app token" 是自给自足的，我不必进行 AuthService 调用。您可以始终使用 Https 并避免中间人，并让 SDK 安全地存储应用令牌。

我听说过一些解决方案，例如在 X 、 Y 、 Z ... 等服务中缓存应用程序信息（app-token）并在本地进行验证。但是，一旦您掌握了我的应用程序密钥和秘密，无论我将其存储在何处，您都可以聚会，而且缓存在单个服务中也是多余的。您最终还会将授权信息存储在缓存中，该缓存可能会快速更改。缓存失效可能是个问题。 ?

请帮忙， 提前致谢。

Answer 1

所描述的场景看起来像是OAuth 2.0 授权与self-contained bearer access tokens 的经典案例。

客户端将在 OAuth 2.0 授权和/或令牌端点进行身份验证并颁发访问令牌。访问令牌可以由签名的JWT 表示，该JWT 在使用 OAuth 2.0 服务器的 RSA 密钥签名的 JSON 对象中编码权限范围和有效性时间范围。 X、Y 和 Z 服务只需要在收到 JWT 访问令牌时检查签名即可清除请求。这将为您节省对身份验证服务的网络调用，并且可以在大约 100 微秒内完成 RSA 签名检查，这比 HTTP 请求（大约数十毫秒或更多毫秒）要少得多。

Answer 2

我会一个接一个地回答你的问题，大多不按顺序

1.缓存 appid 和 appkey

这里的 appKey 就像一个密码，appId 是一个用户名。您不会像在数据库中那样保存密码。我将使用盐进行哈希处理，然后将其保存到数据库中。众所周知，散列是一种方法，即使黑客可以访问数据库，他也无法获取用户的密码。

2.每次调用验证服务器

不是每次都调用身份验证服务器，而是生成一个时间绑定令牌，该令牌将在指定的时间内使用，一旦令牌过期，您可以生成一个新令牌或增加现有令牌的有效性。您可以缓存此令牌而不是缓存 appKey。

注意：如果给予足够的资源和足够的时间，任何密码都可能被破解。资源和时间的成本可能非常巨大