提前致歉，因为这篇文章相当长，可能会有相当的技术性。为了让我们热身，我将首先从启发我编写凭证API的真实故事开始。早在Jenkins被称为Jenkins之前（但无论如何我还是要叫它Jenkins），在CloudBees在Sacha眼里还没有闪现的时候，我管理着几个Jenkins服务器。公司IT擅长发布命令。。。注意：以下电子邮件虽然受到现实的启发，但都是虚构的。发件人："IT安全"主题：公司LDAP服务器中的计算机帐户致："全体员工"CC："LDAP管理员"只有公司IT提供和管理的服务才可以有计算机帐户在公司LDAP服务器中  发件人："IT安全"主题：密码策略收件人："LDAP管理员"请查收附加的新密码政策。要点是：*密码必须至少具有以下每种类型的符号之一：-大写字母-小写字母-一个数字-以下字符之一：？&$@#![]{},./\%^()*所有帐户密码将至少每90天轮换一次。*当一个帐户密码为多个人（即机器）所知时帐户，密码将每30天轮换一次*连续5次登录失败后，帐户将被锁定  发件人："信息服务副总裁"主题：RE:在LDAP中为开发者CI服务器创建计算机帐户致："工程总监"嗨，吉姆，听着，因为你的工程师需要能够管理他们的CI服务器，比如安装新的Java开发包，几乎每周更新应用程序本身以获得新功能它正在被交付，并在其他方面调整各种配置，把机器交给外包IT提供商。我们的IT提供商没有这个软件和那些让他们管理它的引语会被嘲笑如果我把它们放在首席财务官面前的话，就把它们从房间里拿出来。你只需要把应用服务器放在你的工程实验室里你的工程师负责管理。因此，我们的IT安全团队不允许在LDAP服务器中创建一个计算机帐户允许工程师在没有可追溯性的情况下执行操作。-鲍勃 所以，我现在是一名工程师，负责管理三台Jenkins服务器，我们的开发和QA团队正在使用这些服务器来保持我们的诚实和提高生产效率，我还写下了许多其他的理由，以说服工程总监为服务器提交采购订单，甚至给我自由裁量的时间来工作一些Jenkins的开源插件（除了我被分配到与我们的内部工具集成的闭源代码定制插件之外）。在这个世界上，每90天就有一个噩梦萦绕在我心头……密码重置。您可以看到我们的Subversion服务器被链接到LDAP。我们的缺陷跟踪系统与LDAP相连。我们的Jenkins安全域被配置为LDAP。我们的VMware ESX群集已链接到LDAP。所有内容都链接到LDAP。从某种意义上说，这是辉煌的。我只需要记住一个密码。但是每90天密码就要更改一次…每个Jenkins服务器都有15个密码副本，在旧密码被用来触发连续5次登录失败之前，这些副本必须在比赛中进行更新。到了这样的地步，我唯一能想到的解决方案就是在第88天把詹金斯用过的用户从我换成了同事，用tcpdump检查一组作业被触发时Jenkins没有使用我的用户名，然后在第91天切换回去……不用说，即使这样也很痛苦…只是比打电话给自动IT帮助台导航菜单系统并请求密码重置要简单得多…有趣的是，必须让工程总监在同一天为我的帐户批准每10次密码重置。快到几年前，我在为CloudBees工作，必须设计一个凭证API。在设计API时，有一个指导原则是我所珍视的：如果用户无法将其设置为只有一条需要更新的用户名/密码记录，并在适当的地方重复使用该记录，则API失败。这并不意味着用户必须这样设置。如果用户选择在其Jenkins服务器上的50个不同位置重复相同的用户名/密码，那么这是他们的选择，只要是他们可以选择的。那么这意味着什么，它是如何出现在API中的呢？首先，它意味着我们不希望gach duine agus a mháthair（一个爱尔兰成语，字面意思是"每个人和他们的母亲"）实现他们自己版本的用户名密码凭证。我们需要一个标准的用户名/密码凭证实现，它有一个用户名框和一个密码框读了上面的内容，可能会发现我是一个智慧的光辉灯塔，从我在凭证API中编写的第一行代码中实现了这一原则。。。哈！谷歌翻译是你自己的啊哼！我在想什么？好吧，在我的辩护中，我最终做到了……（一路上犯了很多错误……谢天谢地，犯错误是我学习的方式……天哪，我犯了比我应得的更多的错误！）也许我该解释一下。我的第一个想法是如何使用SSH进行身份验证是特定于SSH的事情。配置SSH连接时，您希望能够选择对SSH有效的凭据。因此，我决定使用SSH连接的所有凭据都应该从SSHUser扩展，因为它们的一个共同点是它们都必须有一个用户名。现在，因为我想在特定于SSH的插件中保留特定于SSH的东西，所以没有办法让标准用户名凭证实现SSHUser接口，所以我们在模块之间有一个循环依赖关系。因此，我们最终实现了两个用户名/密码凭据实现。一个用于在SSH连接中使用用户名/密码时，另一个用于希望将同一用户名/密码用于其他目的时。实际上，我们使用类型系统给凭证实例着色，这样我们就可以根据凭证的颜色过滤掉无效凭证。我了解到，以这种方式使用类型系统是一个非常大的错误。为了理解为什么这是一个错误，我需要引入一个概念，我称之为"身份神谕"。也许最好的解释这个概念的方法是举例。当你在GMail中创建一个帐户时，在Google服务器的后面有一个身份存储库，它为你创建一个条目并存储你的密码哈希。当你访问GMail、Google+或YouTube时，最终所有这些应用程序都会咨询Google的Oracle of Identity来验证你的身份。当你在GitHub上创建一个帐户时，GitHub的服务器中也有一个Identity的Oracle。如果您更改GMail密码，则不会影响您的GitHub密码，就像您更改了公司LDAP服务器中的密码（顺便说一下，这是您雇主的标识甲骨文），那么这不会影响您的GitHub密码……但这可能会影响您的GitHub企业密码（因为企业和用户都喜欢单点登录）对于用户名/密码类型的凭据，Oracle of Identity最容易理解，但它也适用于：ssh-keys（如果您有一个服务来分发ssh-authorized\u-keys文件…顺便说一句，NFS支持的网络主节点也算作其中之一）TLS客户端证书OAuth令牌等现在我可以听到人们说"OAuth代币，WTF！这不应该是"我很可能非常同意你，另一方面。。。Q： 在应用程序中存储凭据最安全的方法是什么？A： 不存储任何凭证是最安全的方法。假设我的任务是编写一些服务，比如说它可以按需进行黑鸭式的代码扫描。这个服务不是我们想要一直运行的，但是当我们选择运行它时，它需要访问我们的源代码。现在我可以花很多精力来保护服务，这样它就可以安全地存储所需的凭证，添加入侵检测、凭证滥用检测、监控，或者我可以把它放在一个合理锁定的虚拟机（或容器）中运行，每次使用后我都会将其拆下，并在我想让它做某件事时传递凭证。因为该服务实际上并不存储OAuth承载令牌，而且该服务在不使用时并不存在，所以我可以编写一个更简单的服务这是一个实用的模式…也许它甚至会被复制到其他服务中…然后不久之后，您将有10个不同的服务使用相同的OAuth凭据（因为它们都需要相同/相似的作用域，OAuth服务器将只为请求主机名（即CI服务器）发出一个活动承载令牌，并将新请求视为使先前发出的承载令牌无效的标志）现在我对"应该"如何设计的理解是，这十个服务中的每一个都应该有一个OAuth身份验证层。然后Jenkins可以针对每个服务进行身份验证，给Jenkins每个服务一个唯一的令牌……然后每个服务都提供一个UI来管理身份可以做什么，并管理服务为每个用户提供的OAuth密钥，我们可以在那里为每个服务输入一个单独的密钥，然后我们可以在那里为每个服务输入一个单独的密钥…然后我们可以为每个服务输入一个单独的密钥。。。或者我们可以认识到，决定证书颜色的应该是用户，而不是我们开发者。他们是知道/发现