HTTP URL 令牌标准
我需要在系统中开发一项功能，允许未注册的用户通过经过身份验证的用户生成/发送的 URL 令牌获得一次性系统访问权限。
例如，用户登录并想要共享一条信息，因此系统会生成类似 http://host/page?token=jkb345k4b5234k54kh5345kb34kb34 的 URL。然后，该 URL 被发送给未注册的用户，该用户将遵循该 URL 对通常受保护的数据进行一些有限的访问。
第一个问题 - 是否有任何标准（RFC？IETF？其他？）来定义 URL 生成？我唯一能找到的是 RFC2289 和 OpenToken，但这些都与我需要做的事情没有直接关系，后者是仅处于第二稿状态。
还有另一个设计考虑因素：是否使用单向加密哈希函数并将有效负载存储在本地数据存储中，VS 使用私钥-公钥对并将所有必要的有效负载编码在唯一字符串本身中。
目前，我非常倾向于单向哈希，因为它会给我更多的自由（有效负载大小和生成的字符串之间没有依赖性）并且将来的潜在问题更少（例如，如果我决定添加更多有效负载会怎样 - 如何确保向后兼容性）。最后但并非最不重要的一点是，服务器端私钥的意外暴露将需要在密钥重新生成、更新所有活动实例等方面付出巨大努力。如果选择单向哈希选项，这些问题都无关紧要，但也许我忽略了一些事情？ RFC2289 更喜欢单向加密功能，而 OpenToken 选择密钥对选项。
最后，有人知道有什么 Java 库可以生成这些吗？
提前致谢。
I need to develop a feature in the system which allows unregistered users to get one-off system access via URL token that is generated/sent by an authenticated user.
For example, a user logs in and wants to share a piece of information so the system generates a URL like http://host/page?token=jkb345k4b5234k54kh5345kb34kb34. Then this URL is sent to an unregistered user who would follow the URL to get some limited access to normally protected data.
First question - are there any standards (RFC? IETF? others?) that would be defining URL generation? The only ones I was able to find are RFC2289 and OpenToken, but none of these are directly related to what I need to do and the latter is only in a second draft state.
There is another design consideration: whether to use one way crypto hash functions and store the payload in a local data store VS using private-public key pairs and encode all necessary payload in the unique string itself.
At the moment I am heavily leaning towards one way hash as it would give me much more freedom (no dependency between payload size and generated string) and less potential problems in the future (e.g. what if I decide to add more payload - how to ensure backwards compatibility). Last but not least, accidental exposure of server-side private key would require massive efforts in key regeneration, update of all live instances, etc. None of these problems are relevant if choosing one-way hash option, but maybe there's something I overlook? RFC2289 prefers one way crypto function whereas OpenToken chooses the key pair option.
And finally, is anybody aware of any Java library for generating these?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
另请参阅 http://en.wikipedia.org/wiki/Universally_unique_identifier 和 < a href="https://www.rfc-editor.org/rfc/rfc4122" rel="nofollow noreferrer">RFC4122。在后端内，您需要将生成的 uuid 附加到您的实体，以便稍后可以完成基于 UUID 的验证。
除此之外，大多数情况下，令牌可能包含一些数据（例如版本控制+用户数据），然后使用安全的 MD5 哈希对其进行“混淆/匿名化”。随后，服务器将数据连接起来，并再次比较哈希值。
关于java-lib和uuid请查看 UUID-javadoc。
Also have a look at http://en.wikipedia.org/wiki/Universally_unique_identifier and RFC4122. Inside the backend you would need to attach the generated uuid to your entity so verification based on the UUID can be done later.
Apart from that most often the token could include some data (e.g. versioning+userdata) and then a secure MD5-hash is used to 'obfuscate/anonymize' it. Later then the data is concatenated by server and the hash-values are compared again.
Regarding java-lib and uuid have a look at UUID-javadoc.
生成随机字符串并将其存储在带有凭据的数据库中。
生成的代码需要具有两个属性：复杂性和唯一性。复杂性确保它们无法被猜测，唯一性确保相同的代码永远不会生成两次。除此之外，具体方法并不重要。
生成包含两部分的令牌字符串。第一部分是与时间相关的，其中密钥将以每毫秒可预测的方式递增和变化。第二部分是完全随机的。结合起来，这将为您提供一个独特且复杂的长字符串。
生成令牌时，将其与使用此令牌时授予的凭据一起存储在数据库中。重要的是这些凭据不要编码到字符串中，因为这可以确保字符串不会被黑客攻击。
当用户单击带有令牌的链接时，将该令牌标记为在数据库中使用。更好的是为使用设置一个时间戳，这样它就可以在第一次点击后 24 小时后过期。这种方法使您可以根据项目的需要灵活地实现需求的这一特定部分。
我之前在许多不同的情况下使用过该解决方案，不仅用于一次性系统访问，还用于门票入场代码、礼券代码以及任何一次性使用的东西。使用什么来生成令牌并不重要，重要的是您可以保证其复杂性和唯一性。
Generate random strings and store them in a database with credentials.
The codes generated need to have two properties: complexity and uniqueness. Complexity ensures that they cannot be guessed and uniqueness ensures that the same code can never be generated twice. Beyond this, the specific method doesn't matter.
Generate token strings with two parts to them. The first part is time-dependent, where the key will increment and change in a predictable way with each millisecond. The second part is completely random. Combined, this will give you a long string that is unique and complex.
When you generate the token, store it in the database with the credentials that are granted when this token is used. It's important that these credentials are not encoded into the string, since this ensures that the strings cannot be hacked.
When the user click on the link with the token, mark that token as used in the database. Even better is to set a timestamp for the use, so that it can be expired, perhaps, 24 hours after the first click. This approach gives you the flexibility to implement this specific part of the requirement as necessary for your project.
I've used this solution before in many different cases for not only one-off system access, but also for ticket admission codes, gift certificate codes, and anything that's one-time use. It doesn't matter so much what you use to generate the token, so much as you can guarantee its complexity and uniqueness.
我会这样做：
Here's how I would have done it:
当用户分享一条信息时，您只需要一个令牌。那么，您不能生成一个随机标记，并将其与该信息（例如数据库字段）相关联吗？这比做任何加密的事情要简单得多......
You only need a token when a user shares one piece of information. So, can't you just generate a random token, and associate this with the piece of information (e.g. a database field)? It's a lot simpler than doing any crypto stuff...