0

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

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

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

但，

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

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

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

请帮助，在此先感谢。

4

2 回答 2

0

所描述的场景看起来像是使用自包含不记名访问令牌进行OAuth 2.0授权的经典案例。

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

于 2014-04-01T07:37:53.600 回答
0

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

1.缓存appid和appkey

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

2.每次都调用Auth服务器

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

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

于 2014-02-20T09:11:44.990 回答