2
我知道这个问题已经被问了很多次,形式和形式各不相同,但我对于一些事情还是很不清楚。令人困惑的是,围绕Web的这个主题的资源如何引用没有明确上下文的“用户”。 API密钥是为用户颁发的,访问令牌也是如此,但我不认为API密钥用户与访问令牌用户相同。如何有效使用API密钥和令牌方案来保护REST API?
- 您是否需要针对最终用户客户端的不同实例拥有不同的API密钥?例如,如果我为第三方API构建移动应用程序,每个实例是否保留其自己的API密钥?我不认为他们这样做,但我怎么绑定API密钥,并将令牌一起访问,以表示某个请求来自某个已知用户授权的应用程序的特定实例?如果我是auth提供者,我是否必须跟踪每一个?
- API密钥和访问令牌通常由一对公共密钥和共享密钥表示。作为服务提供者(服务器端),我使用哪一个来验证我收到的消息,API密钥或访问令牌?如果我理解正确,这个想法是每个请求应该带有从API密钥的秘密部分派生的签名,以便服务器可以检查它是否来自可信客户端。现在我有什么使用访问令牌的秘密?我知道访问令牌用于验证系统用户是否已授权应用程序代表他们执行操作,但是访问令牌的哪些部分会对访问令牌密码有用?
- 是从一个(安全)随机数生成的一个散列,和一个时间戳salt是一个很好的API密钥生成策略?
- 是否有(最好是开源的,基于Java的)框架能够完成其中的大部分工作?
那么这是否意味着任何需要用户认证的资源,签名都应该使用访问令牌的秘密进行签名?令牌(这对密钥)是否代表用户授予应用程序的授权?如果应用程序具有不同的实例(例如,在不同的Android设备上有相同的应用程序),是否意味着所有应用程序都会自动授权?嗯...除了那些其他实例不知道这个秘密,除非它保存在他们都使用的中央后端。 – 2014-09-11 07:31:02
对于前两个问题,假设你在谈论Oauth 1。但请记住,没有理由不允许为单个应用程序设置多个凭据。这取决于服务提供商的设计。 – 2014-09-11 08:24:20