2014-09-11 74 views
2

我知道这个问题已经被问了很多次,形式和形式各不相同,但我对于一些事情还是很不清楚。令人困惑的是,围绕Web的这个主题的资源如何引用没有明确上下文的“用户”。 API密钥是为用户颁发的,访问令牌也是如此,但我不认为API密钥用户与访问令牌用户相同。如何有效使用API​​密钥和令牌方案来保护REST API?

  • 您是否需要针对最终用户客户端的不同实例拥有不同的API密钥?例如,如果我为第三方API构建移动应用程序,每个实例是否保留其自己的API密钥?我不认为他们这样做,但我怎么绑定API密钥,并将令牌一起访问,以表示某个请求来自某个已知用户授权的应用程序的特定实例?如果我是auth提供者,我是否必须跟踪每一个?
  • API密钥和访问令牌通常由一对公共密钥和共享密钥表示。作为服务提供者(服务器端),我使用哪一个来验证我收到的消息,API密钥或访问令牌?如果我理解正确,这个想法是每个请求应该带有从API密钥的秘密部分派生的签名,以便服务器可以检查它是否来自可信客户端。现在我有什么使用访问令牌的秘密?我知道访问令牌用于验证系统用户是否已授权应用程序代表他们执行操作,但是访问令牌的哪些部分会对访问令牌密码有用?
  • 是从一个(安全)随机数生成的一个散列,和一个时间戳salt是一个很好的API密钥生成策略?
  • 是否有(最好是开源的,基于Java的)框架能够完成其中的大部分工作?

回答

2

让我试着回答尽可能多的问题。

Apikey VS访问令牌的使用

  • 首先,apikeys是不是每个用户使用。每个 应用程序(开发人员)分配Apikeys。一个服务的开发者注册他们的应用程序,并获得一对密钥 。
  • 另一方面,在使用的上下文中为每个 最终用户颁发访问令牌(例外情况是Client Credential 授予)。
  • 服务提供商可以从使用中的 apikey中识别应用程序。
  • 服务提供商可以使用 访问令牌属性来识别最终用户。
  • 您应该有任何最终用户API,即具有关联的最终用户资源(数据或上下文)的API,受3段Oauth保护。所以访问令牌应该是访问这些资源所必需的。
  • 开发人员专用资源可以通过apikey或双腿Oauth进行保护。这里我指的是Oauth2标准。
  • 当没有HTTPS支持时,首选Oauth1。这样共享密钥不会通过不受保护的通道发送。相反,它用于生成签名。我强烈建议通过HTTP使用Oauth2,并避免使用Oauth1。你和你的API消费者会发现Oauth2更容易实现和使用。除非您有特定的理由使用Oauth v1

作为服务提供商,您可以使用提供Oauth 1和2的Apigee Edge平台。它不是开源的。但是,您可以免费使用它,直到您需要一些高TPS或更高的SLA。

+0

那么这是否意味着任何需要用户认证的资源,签名都应该使用访问令牌的秘密进行签名?令牌(这对密钥)是否代表用户授予应用程序的授权?如果应用程序具有不同的实例(例如,在不同的Android设备上有相同的应用程序),是否意味着所有应用程序都会自动授权?嗯...除了那些其他实例不知道这个秘密,除非它保存在他们都使用的中央后端。 – 2014-09-11 07:31:02

+0

对于前两个问题,假设你在谈论Oauth 1。但请记住,没有理由不允许为单个应用程序设置多个凭据。这取决于服务提供商的设计。 – 2014-09-11 08:24:20

相关问题