OAuth2和OpenID

OAuth2是一个标准的授权协议，并以委派代理的方式进行授权。OAuth2提供一种协议交互框架，使第三方应用以安全的方式，获得用户的访问令牌(access_token)。第三方应用可以使用访问令牌代表用户访问相关资源。OAuth2中定义了以下4种角色：
  • 资源所有者：自然人或会创建资源的系统。资源所有者对资源拥有所有权。
  • 资源服务器：存储受保护的用户资源。
  • 应用程序：准备访问用户资源的程序，如Web应用、移动端应用或桌面可执行程序。
  • 授权服务器：在获取用户授权后，为应用程序颁发访问令牌，从而获取用户资源。
OAuth2的四种授权模式
隐式授权模式
引导用户在登录页面登录，在用户登录成功后，通过授权系统将用户的授权信息回调到第三方应用，在第三方应用拿到授权信息后，便可调用开放能力。
流程
用户访问第三方应用=>第三方应用引导用户向授权系统发起授权=>授权系统做参数校验并重定向到认证系统=>认证成功认证系统回调授权系统给授权系统用户信息=>授权系统生产access_token并重定向到第三方应用设置的回调地址
总结
  • 安全性不高。授权系统回调到第三方应用时，token会直接作为参数在浏览器中显示，有暴露token的风险。
  • 可能无法刷新token有效期
  • 第三方应用所设置的回调地址不是https而是普通的http的话，会带来参数被拦截的风险。
  • 实际应用不多

     

 
授权码授权模式
授权码模式前期的授权流程类似隐式授权模式，不同之处在于授权码模式不再直接返回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=>授权系统向第三方应用返回完整的授权信息
总结
  • 可灵活设置access_token的过期时间，第三方应用可根据需求来刷新access_token
  • access_token是第三方应用通过后段通道请求获取的，不回展示在浏览器上。
  • 授权系统可以设置https请求，第三方应用会被强制使用https获取access_token，确保信息不被拦截
  • code会展示在浏览器的URL中，会把code暴漏出来，但code有效期短且只能用一次，而且需要配合client_secret才能使用
  • 实际工作中应用最多
 
授信客户端密码模式
一般用于共享用户账号体系的第三方应用进行授权的场景。例如，母公司和子公司所开发的第三方应用共享用户账号体系。在该模式下，用户在第三方应用中输入用户名和密码后，第三方应用会直接使用用户名和密码信息获取授权信息。
流程
用户访问第三方应用并输入用户名和密码=>第三方应用从后台向授权系统发起授权请求=>授权系统通过后台接口(一般是内部的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系统可用于所有需要身份认证的地方，既可以应用于单点登录系统，也可以用于共享敏感数据时的身份认证。
流程
  1. 现有一个支持OpenID的X网站(openId使用者)，在其登录页面有个OpenID标识输入框，用户在该输入框中输入OpenId标识来完成登录认证。
  2. 用户Alice在Y网站(OpenID提供者，网址openid-provider.org)注册了一个OpenId标识，即alice.openid-provider.org。Alice可使用该OpenId标识登录任何与Y网站完成对接的OpenID使用者系统。
  3. 如果X网站已经完成了与Y网站的对接，那么Alice想使用这个标识登录X网站，只需在X网站的OpenID等了表达中填入自己的OpenID表示，并单击“登录”按钮即可。
  4. 因为标识是一个URL，所以X网站首先会将这个标识转换为典型格式，即https://alice.openid-provider.org，并将用户的浏览器重定向到Y网站，用户在Y网站输入用户名和密码完成认证。
  5. 在Y网站认证完成后，Y网站会询问Alice是否信任X网站(optional)，然后会重定向到X网站提供的URL完成openId认证，同时，X网站也会通过这个URL接收到Y网站传来的用户的身份信息。
  6. X网站在收到用户的身份信息后需要确定收到的信息确实来自Y网站。可以通过X和Y在集成时协商的signing key生成jwt进行相关认证。或X网站向Y网站发起一次验证请求来保证收到的数据的正确性，这种验证方式是无状态的。
  7. Alice的标识被X网站验证后，Alice便以alice.openid-provider.org的身份登录X网站。X网站可以保存session，如果这是Alice第一次登录X网站，则提示Alice输入一些X网站所需的信息，以便完成注册。
总结
  • OpenId是基于OAuth建立的用户认证体系。它的目标是定义一种标准，OpenID提供者和OpenID使用者都按照标准进行系统实现，以便可以完成基于OpenId的认证登录操作。
  • 去中心化的网上身份认证系统。任何用户注册过的网站，只要提供了OpenID对接能力，就可以作为用户的OpenID提供者。但这种去中心化的前提是，OpenID使用者与相应的OpenID提供者已经对接完成。在实际使用中，OpenID使用者需要对接很多OpenID提供者。
  • 用户不需要记住自己在OpenID使用者中的用户名和密码，但要记住自己在OpenID提供者系统中的用户和密码
  • OpenID使用者要对接OpenID提供者的回调，保存用户的授权信息。OpenID提供者要验证OpenID使用者，这是因为不是任意的回调地址都可以进行请求。

     

 
OpenId解决了什么OAuth2没解决的问题？
在OAuth2的授权流程中，最终的授权结果为access_token，通过access_token可以获取数据并使用开放平台所提供的功能。access_token的特点是随时可能发生变化，因此无法用来唯一标识一个用户。因为通常第三方应用需要对当前进入系统的用户进行唯一标识，而access_token在很多授权模式下都会发生改变，所以，openId在OAuth2的基础上提供了用户在第三方应用中的唯一标识。
OpenID为用户在第三方应用中提供唯一标识，需要具备以下特性：
  • 同一用户的OpenID在第三方应用中是唯一的
  • 授权系统需要维护开放平台所在系统UserID与OpenID之间的对关系，用来支持第三方应用和开放平台之间进行用户匹配
  • 为保障用户信息安全，同一用户在不同第三方应用中的OpenID必须是不同的。防止多个第三方应用私下分享各自的用户信息
如果需要多个第三方应用共享信息，比如同一组织下的多个应用需要共享信息，再引入一个UnionID，一个UnionID可以对应到多个不同的OpenID。
posted @ 2025-11-01 22:41  软件心理学工程师  Views(1)  Comments(0)    收藏  举报