无需浏览器和 SSL/质询响应模型的 OAuth
我们计划使用 REST-ful 开发移动应用程序。我们希望应用 OAuth 1.0a 而不是 OAuth 2.0，因为我们不使用 SSL。我们也不想使用网络浏览器（我们认为基于 PIN 的用户体验不友好）。我们知道正常的 OAuth 流程是不可能的。
我不是安全架构方面的专家，但我在网上谷歌了一下，看到有人使用像挑战响应模型这样的方法登录来实现。
如果我们的应用程序不需要保证用户名的安全，并且用户信任我们在我们的应用程序中输入密码，那么可以使用此方法来交换访问令牌吗？有什么缺陷吗？
- 服务器响应未经授权的请求令牌后，客户端开始质询-响应流程。
客户端发送请求到http://www.example.com/login，参数如OAuth需要：oauth_consumer_key、oauth_token、oauth_signature_method、oauth_timestamp、oauth_nonce 以及附加的 username 参数 username="username"， password 参数根据用户密码（存储在服务器中）计算得出，oauth_nonce 具有 KDF 密钥派生函数/哈希函数。客户端使用 OAuth 描述计算请求签名，但在省略密码参数后发送带有参数用户名和其他必需参数的请求。
服务器检查请求并返回访问令牌。
We have a plan for developing a mobile application using REST-ful. We want to apply OAuth 1.0a not OAuth 2.0 because we don't use SSL. We also don't want to use web browser (we think PIN-based UX is not friendly). We know it's impossible with normal OAuth flow.
I am not an expert in security architecture but I google on the Net and see someone has a implemention using a method login like challenge-response model.
If our app don't need to keep username secure and users trust us with inputting their password in our app, can this method being use to exchange access token? Is there any flaw?
- After server response unauthorized request token, client begin challenge-response flow.
Client send request to http://www.example.com/login, with parameter like OAuth require: oauth_consumer_key, oauth_token, oauth_signature_method, oauth_timestamp, oauth_nonce and the additional username parameter username="username", the password parameter calculated from the user's password (which is stored in server), oauth_nonce with KDF key derive function/hash function. Client calculate request signature with OAuth description but send the request with the parameter username and other required parameters after omitted the password parameter.
Server check the request and return access token.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我相信您所描述的内容与 Twitter 的 xAuth 非常相似，除非您计划使用您的自己的客户端密码加密而不是 SSL。
我会阅读他们的 xAuth 文档以查看经过尝试和测试的方法，并考虑使用 SSL 进行令牌请求步骤。
I believe what you are describing is very similar to Twitter's xAuth except you are planing to use your own client side encryption of the password and not SSL.
I would read their xAuth documentation to see a tried and tested method and consider using SSL for the token request step.