常用的凭证缓存解决方案？
我对应用程序中的凭据缓存有疑问。我在网上搜索了这个问题的解决方案，但没有找到任何东西（这真的很令人惊讶，因为这是每个 Facebook、Twitter 和电子邮件客户端应用程序都必须处理的问题）。
我的问题是这样的：
假设我正在构建一些简单的 Twitter 客户端。我不想强迫用户每次都输入密码。大多数应用程序如何解决这个问题？在某些时候，客户端需要进行 API 调用来进行身份验证（其中包括密码，通常为纯文本形式）。但是，显然，以纯文本形式将密码保存在某处并不是正确的解决方案。那么，大多数应用程序如何安全地做到这一点呢？我想如果密码被加密，您可以将密码缓存在文件或数据库中，但是如何安全地存储解密密钥呢？或者它是在运行时使用来自客户端计算机的唯一信息作为种子生成的？
有没有任何资源（文章、书籍等）讨论这个问题？大多数应用程序如何处理这个问题？
谢谢！
I have question about credential caching in applications. I've searched around on the net for solutions to this problem, but I haven't found anything (which is really surprising, since this is something that every Facebook, Twitter, and email client application has to deal with).
My question is this:
Let's say I'm building some simple Twitter client. I don't want to force the user to enter their password every time. How do most applications tackle this problem? At some point, the client needs to make an API call to authenticate (which includes the password, which is usually in plain text). However, saving the password in plain text somewhere not the correct solution, obviously. So, how do most apps do this safely? I suppose you could cache the password in a file or db if the password is encrypted, but then how do you safely store the decryption key? Or is it generated at runtime using unique information from the client machine as a seed?
Are there any resources (articles, books, etc.) that talk about this? How do most apps handle this?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
单点登录 (SSO) 设置通常通过提供集中式方法来使用某种类型的会话 ID 生成、分发和验证密钥来实现您所描述的目的。
请参阅一种方法（由 StackExchange/StackOverflow 使用）：
< a href="http://openid.org/" rel="nofollow noreferrer">http://openid.org/
这是我不知道的事情：此类功能称为 联合身份。例如，我工作的网络系统提供（但不要求）Shibboleth。请参阅此处查看选项列表：
http://en.wikipedia.org/wiki/Category:联合身份
Single-sign-on (SSO) setups accomplish what you describe typically by providing centralized methods to generate, distribute and validate a key using some type of session ID.
See for one method (used by StackExchange/StackOverflow):
http://openid.org/
Here's something I didn't know: This category of functionality is known as Federated Identity. For instance, our web system where I work offers (but doesn't require) Shibboleth. See here for a list of options:
http://en.wikipedia.org/wiki/Category:Federated_identity