MBaaS世界中的应用密钥和应用密钥的意义

我正在构建移动后端服务。我想知道，想象一下像身份验证服务这样的服务为购买一系列服务（逻辑上称为应用程序）的用户提供了应用程序密钥和应用程序密钥。MBaaS世界中的应用密钥和应用密钥的意义

假设有服务X，Y，Z等，也是一个AuthService。

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

但是，

既然不能验证(appkey , appsecret)当地因为有作为的(username , password)一样好，我必须做的一个AuthService服务调用，以找出是否API调用是有效的。但是这会影响性能，因为每次调用服务X实际上都是两个服务调用。

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

我听说过诸如在X，Y，Z等服务中缓存应用程序信息（应用程序令牌）以及本地验证等解决方案。但是一旦你掌握了我的应用密钥和秘密，无论我存储在哪里，都可以进行派对，而且在单个服务中缓存也是多余的。您最终还会将授权信息存储在可能会快速更改的缓存中。缓存失效可能是一个问题。？

请帮忙，在此先感谢。

来源

2014-02-19 Karthik Avjs

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

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

来源

2014-04-01 07:37:53

我会回答后，其他的问题之一大都没有按顺序

1.缓存的appid和对AppKey

这里的AppKey是类似于密码，APPID是一个用户名。您不会像在数据库中那样保存密码。我将使用盐进行散列，然后将其保存到数据库中。据了解，哈希是一种方式，即使黑客访问数据库，他也无法获得用户的密码。

2.Calling验证服务器每一次

而不是调用auth服务器每一次，产生绑定令牌的时间，这将用于它指定的时间，并且一旦令牌过期你可以生成新的令牌或增加现有令牌的有效性。你可以缓存这个令牌而不是缓存appKey。

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

来源

2014-02-20 09:11:44 kishore

感谢您的回复。我似乎没有清楚地提到我的问题。我的意思是缓存的应用信息，我指的是应用令牌，而不是应用密钥。所以，当我接受它时，您同意使用应用程序令牌。第二个问题显然是将其缓存在服务中，并将其发送回设备并（使用SDK）安全地存储它。令牌刷新/增加现有令牌的有效性应该是该设备的问题，因为它可能会导致连接松动（可能需要很长时间）。为什么服务必须一直照顾它？ –

当sdk为某些数据返回令牌时，服务应验证它以确保这是实际的应用程序提出请求 – kishore

MBaaS世界中的应用密钥和应用密钥的意义

回答

相关问题