Google App Engine 作为移动应用程序的身份验证服务器
我正在尝试利用 Google App Engine 作为原生在 Android 上运行的移动应用程序的身份验证服务器。用户名和密码将存储在 GAE 中，我的目标是能够使用 GAE 存储和验证来自移动应用程序的凭据。这可能吗？我研究过 OAuth 和 JSON，但我认为我没有适当的设置。
另外，如果我以错误的方式处理这个问题，请指出我正确的路径。
I am attempting to utilize Google App Engine as an Authentication Server for a mobile application that runs on android natively. User names and passwords will be stored in GAE and my goal is to be able to both store and verify credentials from the mobile application using GAE. Is this possible? I've looked into OAuth and JSON, but I don't think I have the proper setup for that.
Also, if I'm going about this the wrong way, please point me to the proper path.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您有兴趣在 GAE 实例中实现更像 API 的实现，我肯定会更多地研究 OAuth。但如果您只对验证这一移动应用程序的凭据感兴趣，那么您无需走那么远。
幸运的是，您可以通过 SSL 调用您的 GAE 实例，这意味着您可以卸载所有握手和加密业务。然后我只需使用 http-basic 身份验证< /a>，或者简单地发送用户 ID 和加密密码作为请求中的参数。
iPhone 上有一个用于存储密码的 KeyChain，也许 Android 上有一个对应的 KeyChain？无论如何，请确保在设备和 GAE 数据存储中存储加密的密码。验证凭据时发送加密密码。您永远不应该知道用户的明文密码。这将提供一定程度的模糊性，我认为这已经足够了（通过 SSL 发送时肯定如此）。
然后您只需返回帐户凭据是否已验证即可。
If you are interested in having a more API-like implementation in your GAE instance, I would definitely look more into OAuth. But if you are only interested in validating credentials for this one mobile application then you need not go that far.
Fortunately you can call your GAE instance over SSL, that means that you can offload all the business of handshaking and encryption. Then I would simply use either http-basic authentication, or simply send user-id and encrypted password as parameters in the request.
On the iPhone there is a KeyChain for password storing, maybe there is an Android counterpart? Anyway, make sure to store passwords encrypted on the device and in the GAE-datastore. Send the encrypted password when validating credentials. You should never know your user's clear text passwords. That would provide a level of obscurity which I think is enough (definitely so when sent over SSL).
Then you can simply return whether the account credentials are verified or not.
如果“存储凭据”是指存储用户名和密码，那么我想您的处理方式是错误的。无论您谈论的是 OAuth 还是 OpenID，其想法都是您永远不会看到或无法访问委托身份验证机制的密码（也许也不是用户名）。相反，您会收到一个身份验证或授权令牌来完成您的工作（对于 OpeniD，您会收到有关此人的一些元信息，例如名字/姓氏和电子邮件地址）。
顺便问一下，您是否考虑过第三方，例如 Janrain？
If by "storign credentials" you mean storing username and password, then I imagine you are going about this the wrong way. Whether you are talking about OAuth or OpenID, the idea is that you never see or have access to the password (and perhaps not username either) of the delegated authentication mechanism. Instead you receive an authentication or authorization token to do your work (and in the case of OpeniD, some meta information about the person like first / last name and e-mail address).
By the way, have you considered a 3rd party, such as Janrain?