OAuth 时间戳在移动设备上有问题吗？
我有一个使用 OAuth 进行身份验证的 REST API。该API将主要用于移动应用程序。
一位开发移动应用程序的开发人员（他似乎不熟悉 OAuth）询问了时间戳限制。他担心如果用户的时钟关闭，应用程序将无法工作，因为如果关闭时间超过 5 分钟（我的应用程序当前使用的限制），请求将被假定为重放攻击，并被拒绝。
我想知道，您（无论是应用程序开发人员还是 API 开发人员）在野外遇到过这个问题吗？你是如何解决这个问题的？时间戳同步的合理限制是什么？
I've got a REST API that uses OAuth for authentication. This API will primarily be used for mobile applications.
One of the developers working on a mobile app (he seems to be unfamiliar with OAuth) asked about the timestamp restriction. He was concerned that if the user's clock is off, the app will not work, because if it's off by more than 5 minutes (the current restriction my app uses), the request will be assumed to be a replay attack, and be rejected.
I'm wondering, have you (either as app developer or API developer) run into this problem in the wild? How have you worked around it? What is a reasonable restriction on the timestamp synchronization?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我只是有这个完全相同的问题，在仔细阅读文档后，我认为我以与您相同的方式思考，完全搞砸了时间戳的实现，请检查一下：
http://oauth.net/core/1.0/#nonce
除非服务提供商另有规定，否则时间戳以自 1970 年 1 月 1 日 00:00:00 GMT 以来的秒数。时间戳值必须是正整数，并且必须等于或大于之前请求中使用的时间戳。
I just had this exact same question and after doing a double take on the documentation I think that I have entirely screwed up the implementation of the timestamp by thinking in the same way you were, check it out:
http://oauth.net/core/1.0/#nonce
Unless otherwise specified by the Service Provider, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. The timestamp value MUST be a positive integer and MUST be equal or greater than the timestamp used in previous requests.