OAuth2是一个标准的授权协议，并以委派代理的方式进行授权。OAuth2提供一种协议交互框架，使第三方应用以安全的方式，获得用户的访问令牌(access_token)。第三方应用可以使用访问令牌代表用户访问相关资源。OAuth2中定义了以下4种角色：
OAuth2的四种授权模式
隐式授权模式
引导用户在登录页面登录，在用户登录成功后，通过授权系统将用户的授权信息回调到第三方应用，在第三方应用拿到授权信息后，便可调用开放能力。
流程
用户访问第三方应用=>第三方应用引导用户向授权系统发起授权=>授权系统做参数校验并重定向到认证系统=>认证成功认证系统回调授权系统给授权系统用户信息=>授权系统生产access_token并重定向到第三方应用设置的回调地址
总结
实际应用不多
授权码授权模式
授权码模式前期的授权流程类似隐式授权模式，不同之处在于授权码模式不再直接返回access_token，而是返回給第三方应用有效期较短的code。第三方应用再使用code、client_id和client_secret，通过HttpClient发起post请求，从而获取access_token。
Response:
{
"access_token": "xxx",
"expires_in": 86400,
"refresh_token": "xxx",
"refresh_expires_in": 864000,
"open_id": "xxx",
"scope": "xxx",
"token_type": "bearer"
}
open_id:用户在第三方应用的唯一标识
scope:第三方应用的权限
第三方应用在获取信息后，首先根据open_id将用户绑定到系统中，然后使用refresh_token刷新access_token有效期。open_id可用于识别用户并保存相关信息，access_token可调用用户在开发平台的相关资源。‘
流程
用户访问第三方应用=>第三方应用引导用户向授权系统发起获取code的请求=>授权系统验证参数并重定向到认证系统=>认证成功认证系统回调授权系统给授权系统用户信息=>授权系统生成code并重定向到第三方应用设置的回调地址=>第三方应用通过code/client_id/client_secret到授权系统获取access_token=>授权系统返回access_token和完整的授权信息=>使用refresh_token刷新token=>授权系统向第三方应用返回完整的授权信息
总结
授信客户端密码模式
一般用于共享用户账号体系的第三方应用进行授权的场景。例如，母公司和子公司所开发的第三方应用共享用户账号体系。在该模式下，用户在第三方应用中输入用户名和密码后，第三方应用会直接使用用户名和密码信息获取授权信息。
流程
用户访问第三方应用并输入用户名和密码=>第三方应用从后台向授权系统发起授权请求=>授权系统通过后台接口(一般是内部的RPC接口)验证用户信息=>认证系统校验成功后会返回用户的相关信息=>授权系统向第三方应用返回access_token信息。
总结
授信客户端密码模式会将用户的认证信息(用户名/密码)直接暴露给第三方应用，这意味着开放平台必须对第三方应用完全信任，同时第三方应用需要有能力保障用户的信息安全。所以在实际工作中，该模式的使用场景一般为信任的第三方应用(包括子公司、KA客户等)，应用场景较少。
授信客户端模式
常用于第三方应用直接访问开放平台的场景，在这种场景下不需要用户进行授权，而是由第三方应用直接发起授权，并获取授权信息。
授信客户端模式在实际应用中有变种授信客户端模式，主要用于自研应用的授权，即自研应用通过传递自身的client_id和client_secret，获取在创建应用时被赋予的所有权限。
一般用户在创建自研应用时会绑定自己的账号，所以获取的权限为绑定账号的权限。
流程
注册为自研应用时，第三方应用的授权流程
第三方应用发起绑定用户信息的请求=>授权系统通过后台接口验证用户信息=>认证系统校验成功后会返回用户的真实信息=>在授权系统中绑定用户信息与应用信息=>授权系统向第三方应用返回绑定成功的信息
注册为非自研应用时，第三方应用的授权流程
第三方应用向授权系统请求获取access_token的信息=>授权系统向第三方应用返回access_token信息。
总结
在OAuth2所定义的授信客户端模式中，主要是开放平台将开放系统中与用户无关的功能开放给第三方应用。在变种授信客户端模式中，由于已经将开放系统的用户与第三方应用进行了绑定，因此在进行授权时，可以获取所绑定的用户数据和相关功能。这种变种授信客户端模式一般用于自研应用的授权场景。
OpenId
OpenId是一个以用户为中心的数字身份识别框架，具有开放、分散、自由等特点。
OpenId的核心理念:OpenId可以通过URI认证一个网站的唯一身份，也可以通过这种方式作为用户的身份认证。
目前的网站依靠用户名和密码登录认证，这就意味着用户在每个网站都需要注册用户名和密码。如果使用OpenID，那么网站地址(URI)就是用户名，而密码安全地存储在一个OpenID服务网站上，用户登录时只需输入自己的URI，不需要输入密码。
登录一个支持OpenID的网站非常简单(即便是第一次访问这个网站也一样)。在输入注册好的OpenID用户名后，登录的网站会跳转到OpenID服务网站。在OpenID服务网站输入密码(或其他需要填写的信息)，认证通过后，会跳转到登录的网站，只需登录的网站识别登录信息后，即可登录成功。
OpenID系统可用于所有需要身份认证的地方，既可以应用于单点登录系统，也可以用于共享敏感数据时的身份认证。
流程
总结
OpenID使用者要对接OpenID提供者的回调，保存用户的授权信息。OpenID提供者要验证OpenID使用者，这是因为不是任意的回调地址都可以进行请求。
OpenId解决了什么OAuth2没解决的问题？
在OAuth2的授权流程中，最终的授权结果为access_token，通过access_token可以获取数据并使用开放平台所提供的功能。access_token的特点是随时可能发生变化，因此无法用来唯一标识一个用户。因为通常第三方应用需要对当前进入系统的用户进行唯一标识，而access_token在很多授权模式下都会发生改变，所以，openId在OAuth2的基础上提供了用户在第三方应用中的唯一标识。
OpenID为用户在第三方应用中提供唯一标识，需要具备以下特性：
如果需要多个第三方应用共享信息，比如同一组织下的多个应用需要共享信息，再引入一个UnionID，一个UnionID可以对应到多个不同的OpenID。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。