用户自我识别的过程在一个应用程序的工作流程中根深蒂固，这个工作流程结合用户名、密码功能，也成为初学者创造软件更为优秀的一部分，但是这个最后的过程往往令人厌烦，对于用户来说“另一个用户名/密码”通常被认为是和数字世界中用户所需的大量凭证相悖。该凭证并且使得软件风险承担者和设计者因为要求“另一个用户名/密码”避开了用户而感到厌倦。所以下一步，我们将研究一项叫做OpenID的措施，该措施意在利用Web服务时来减轻这个负担。

　　OpenID通过将凭证储存在‘云’进行工作，应用程序提供能够杠杆作用这一应用程序工作流程中相同的标识。这是一个双赢局面，人们在不同领域巡览时不需要记住众多的登录凭证。应用程序提供者不用为这个类型保存数据库，同时也使用户免于创建新的用户名、密码二进制组合码。

　　从终端用户的角度考虑，OpenID的主要特征是分散型设计，该设计向用户传达完全控制信息储存的地点和方式。该过程和Web的其他的标识系统明显不同，例如Microsoft's Passport中所有的信息由单独实体控制，后者是家私营公司。在一家公司层面，OpenID能够在自身基础结构上生产副产品，使得公司能够在准许各部门和伙伴运用这些凭证的同时，紧紧的锁定用户名和密码。

　　既然我们已经介绍了理论，让我们研究在运用OpenID服务时涉及的实际步骤。假设你到达了应用程序工作流程中的一点，你要求用户在这点上验证身份，并且给用户OpenID提示：用户应该在哪一点进入OpenID。这很像一个URL 例如: https://me.yahoo.com/a/john_doe.，用户就会重新定向到他的OpenID提供者，证实自己的身份为john_doe。如果成功的话，OpenID提供者将在你的应用程序里发送标记，确认用户身份。下面的数据展示了该过程：

　　·向用户展示OpenID提示
　　·用户通过OpenID提供者确认身份
　　·用户被重定向验证身份

　　在这一点上，你只有标记，而绝对没有某一特定用户的任何信息，但是你拥有一个密码支持的身份，在这个基础上你可以开始收集数据了，如姓名，地址、及其他你想获取的个人信息。如果过多的问题导致个人信息超载，你还是应该放松用户。你已经为人们进入新应用程序，解除了一个很大的障碍，不必迫使他们建立“另一个用户名/密码”。

　　在这样的保护下，整个OpenID验证过程以众多Web服务相互通信的形式完成循环。你可以发现一系列的OpenID库帮助你用Java, Python, PHP, C# and Perl,等不同的语言执行OpenID。同样如果你的公司想有效的使用自己Identity Servers补充或取代某些东西，例如用OpenID取代LDAP。你同样可以发现一系列针对不同需求用不同语言编写的Identity Servers 。

　　最后，伴随着最新兴的技术，出现了典型的难题：如果有足够的用户，用户就会支持OpenID，并且只要有充足的提供者，用户就会选择OpenID。那么此时OpenID支持在哪呢？如果你仔细观察先前展示的那些映射，你就会发现Yahoo就是OpenID提供者，考虑到市场拓展和成千上万的用户帐户——最后的公司管理组织，该公司是OpenID发起者与之签署最大协议的公司。加入Yahoo行列中来吧！支持OpenID的公司同时也拥有丰富的用户群如AOL、法国电信（橙色）、WordPress。当然我们也不应该忘记任何公司都能成为自己的OpenID提供者，也拥有大型提供者一样的功能。

　　所以不管你是想完全使一个应用程序设计完全免除用户、密码问题，还是为自己在行业中蒸蒸日上公司寻找标识管理技术，OpenID提供了一个很好的方案，Web服务展示的同样原则巩固了这一方案。当终端用户意识到自己不需要记住“另一个用户名/密码”时，他们就会为有这样的选择而表示赞赏。