openID学习总结

openID学习总结

背景

最初，网站需要记录用户认证信息如用户名和密码，用户需要提供认证信息以登录网站并使用网站中的其他功能。在一开始，这种方式是可行的，对网站提供商而言可以绑定用户、维护网站的用户群。然而，当网站的数量急剧增加，大量的认证信息给用户带来了巨大的负担。
所以，人们就开始设想无密码登录。无密码登录对于拥有多个网站或应用的企业来说尤为重要，毕竟每登录一个网站或安装一个APP就注册一个认证信息是很“睿智”的行为。
openID无疑是无密码登录的佼佼者，Google，Facebook等大公司都在使用这种方式。

openID简介

openID 可以提供了一种终端用户证明自身身份的方法，这种方法不需要当前网站（Relying Party，RP）访问用户的认证信息如密码或邮箱地址等敏感信息。
openID去中心化得（分散的），没有一个中央的认证机构批准或注册RP或OP(openID Providers).并且终端用户可以自由的选择使用哪一个OP，并且如果更换openID提供商用户也可以保留他们的标识符。
虽然歇息中没有要求必须使用JavaScript或现在浏览器，但openID的认证方案符合AJAX风格。这意味着终端用户无需离开他们当前的网页就可以向RP证明自己的身份。
openID身份认证仅使用标准的HTTP（S）请求和响应，因此不需要用户端软件有任何特殊的配置，openID与Cookie、RP或OP回话管理的机制无关。

openID工作原理

openID的细节在协议文档中有所描述，协议文档地址在这里。这里以较为宏观的视角介绍其工作原理，协议概要的原文如下：

1. The end user initiates authentication by presenting a User-Supplied Identifier to the Relying Party via their User-Agent.
2. After normalizing the User-Supplied Identifier, the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user uses for authentication. It should be noted that the User-Supplied Identifier may be an OP Identifier, as discussed in Section 7.3.1, which allows selection of a Claimed Identifier at the OP or for the protocol to proceed without a Claimed Identifier if something else useful is being done via an extension.
3. (optional) The Relying Party and the OP establish an association – a shared secret established using Diffie-Hellman Key Exchange [RFC2631]. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response.
4. The Relying Party redirects the end user’s User-Agent to the OP with an OpenID Authentication request.
5. The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document.
6. The OP redirects the end user’s User-Agent back to the Relying Party with either an assertion that authentication is approved or a message that authentication failed.
7. The Relying Party verifies the information received from the OP including checking the Return URL, verifying the discovered information, checking the nonce, and verifying the signature by using either the shared key established during the association or by sending a direct request to the OP.

在详细说明之前，首先需要明确几个名词、

• Relying Party， 依赖方，即当前想要通过openID来认证当前用户的应用，简称为RP
• OpenID Provider， 认证提供者，即真正对用户信息进行验证的一方，简称OP

openID的工作流程为：

1. 用户输入一个用于认证的URL（这正是openID的哲学，即：URL可以用来唯一标识一个网络资源，那么也同样可以使用URL标识一个用户，但是这里并非是说每个人都有一个不同的URL这么简单）
2. RP方拿到这个URL，解析其中的信息，获取到OP的server，delegate等相关信息
3. （可选的）RP根据得到的OP的信息和OP沟通，确定一个秘钥。OP方使用这个秘钥对用户的信息进行签名，而RP方获取到这个秘钥可以在后续过程中直接验证用户发来的签名是否是正确的，不需要每次认证都要讲用户的信息发送给OP方。
4. RP方通过得到的OP信息，将用户重定向到OP方。
5. OP方验证用户是否持有这个URL。OpenID并没有约束需要如何验证，一种简单的方式就是要求用户提供用户名和密码。这样也就验证了这个用户是合法的。
   （可以发现，RP重定向到OP，而真正的验证在OP方，用户输入的敏感信息如密码，邮箱等不会被RP获得）
6. OP将用户重定向到RP提供的return_to_url（这个应该是在步骤5进行时RP将此信息通知了OP），也即返回RP方并携带了认证成功或失败的信息（如果步骤三执行狗，则携带了通过秘钥签名过的参数）
7. RP方验证返回的URL，验证得到的信息，验证nonce，如果第三步执行的话则使用秘钥验证签名参数，如果没有第三部，则发送验证请求到OP方，问他这个签名是否是你签的，最终OP方会返回。

还有一些细节没有讲清楚，后面再仔细写一下。有不正确的地方欢迎指正。