OpenID是一个以用户为中心的开放的、分散的、自由的用于网络上用户身份验证的身份验证解决方案。这种方案可以让用户使用唯一的URL地址，就可以在任何支持OpenID认证的网站上登录和应用，我们可以用它建立跨域、跨应用的登录（如使用同一URL地址登录你的blog和相册等），它犹如一把“万能钥匙”可以登录所有支持OpenID认证的网站和应用，甚至我们可以用自己的个人网站URL（如blog地址）作为OpenID的登录钥匙，用户可以清楚的控制哪些信息可以被共享，可以为不同的网站和应用建立不同的账户和用户资料，绝妙地解决了多个账户同步和管理地问题。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
目前AOL、yahoo、Blogger、LiveJournal等很多网站都已经支持OpenID，另外微软也表示要支持OpenID。另外，OpenID增加了对Firefox3和微软Windows Vista的支持。
基本工作流程
下面的图表展示了OpenID2.0草案的基本工作流程。它展示了在终端用户 （End User）、外部站点（Relying Party是个示例站点）和OpenID验证服务器（OpenID Provider）之间的交互过程（最常见的认证流程）。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
用户登入外部站点的过程主要分为以下六个步骤：
1． 用户提供一个身份地址（以URL格式）给外部站点；
外部站点通过GET和POST方法获得用户地身份地址；
2． 外部站点通过身份地址取得OpenID验证服务器地址；
一般情况下就是用户输入地URL地址；
3． 外部站点与OpenID验证服务器进行关联（可选）；
为了能够与OpenID验证服务器安全的通信，外部站点需要向OpenID验证服务器请求一个协议。如果有现成的可以使用的协议，则用现有的协议，否则，通过Diffie Hellman的方法获得一个共享密匙。被标为“可选的”，这是因为OpenID协议还允许外部站点直接请求认证（不作关联）、并且接着请求对认证信息进行验证。这样外部站点可以不保有关联权柄信息，以实现无状态通讯。而这种方式被推荐用于执行与OpenID服务器之间的相关通讯，但如果不能使用此方式的话，就必须创建上面讲的关联方式。
4． 外部站点将用户重定向到OpenID验证服务器；
OpenID验证服务器接受一个包含所有外部站点需要用来验证用户的信息，如果用户已经登陆（有COOKIE）并且他已经同意发送他的身份信息给应用服务器的话，第5步可以跳过；
请注意： 外部站点并没有直接发送HTTP请求到OpenID认证服务器，而是重定向到OpenID认证服务器页面。由于这样使得OpenID认证服务器能够从用户浏览器中读取cookie而没有将任何认证细节泄露给外部站点，因此这个过程是安全的。
5． OpenID验证服务器回应外部站点地认证请求；
OpenID验证服务器通过COOKIE或用户输入用户名＋密码验证用户是否登录。登录后判断是否允许外部站点的认证请求，如已配置过则直接返回认证响应信息；如果没有配置过则显示判断页面，在页面上显示外部站点的资料和用户自己的身份资源，让用户选择是否允许响应外部站点的请求，以及用那种身份来响应，最后返回用户选择的认证响应信息；
6． OpenID验证服务器重定向外部站点；
外部站点验证发自OpenID验证服务器的间接认证回应信息。