两条腿的 OAuth 和私有 API？
我最近阅读了一个关于简单、安全的 API 身份验证系统的问题，并看到 2-腿式 OAuth 是一个很好的解决方案。但是假设我只是在创建自己的 iPhone 应用程序，并且希望它能够与我自己的私有 API 进行交互。两条腿的 OAuth 适合这种情况吗？采取这条路线有什么缺点吗？
I recently read a question about a simple, secure API authentication system and see that 2-legged OAuth is a good solution to go with. But say I am just creating my own iPhone app, and would like it to interface with my own private API. Is 2-legged OAuth appropriate in this situation? Are there any disadvantages to taking this route?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
iPhone 客户端的用户是否正在与某人一起登录，或者您只是想验证客户端的身份？
如果是前者，则使用 oauth 并让用户登录到某个 openid 提供商。这实际上就是这个意思。
如果是后者（听起来这就是您正在做的事情），只需创建一些秘密并将其作为 get 请求附加到所有内容并通过 https 进行操作。这听起来很不安全，但你做的任何其他事情都会同样糟糕。您制作的任何加密/w/e 解决方案都将涉及将秘密写入您的代码中。如果有人掌握了这个秘密（例如通过反编译器），那么他们就可以伪造您使用的系统。
Is the user of the iphone client logging in with someone or are you just trying to authenticate the client ?
If the former, then use oauth and have the user log in to some openid provider. Its actually what that is meant for.
If the later ( and it sounds like this is what you are doing), just create some secret and append it as a get request to everything and operate over https. It sounds insecure, but anything else you do will be just as bad. Any crypto/w/e solution you make will involve baking a secret into your code. If someone grabs that secret ( via say a decompiler) then they can fake w/e system you use anyway.