5 分钟部署一个 OAuth2 服务并对接 Shibboleth-IdP 3.4.6

Posted 2023-04-07

参考技术A 这还是一个标题党。

OAuth2 现在已经是开放授权协议的事实标准，你可以看到几乎所有的 xxx 开放平台均采取的 OAuth2 协议来进行授权。而在 Authorization Code 模式的基础上结合 JWT ，标准化的 userinfo endpoint 和服务发现，就成了 OpenID-Connect。当然即便不加上这些限定，OAuth2 在 Authorization Code 模式下，也通常被用作统一身份认证的解决方案提供给用户。而由于 OAuth2 与 CAS 不同，缺乏 Apereo CAS 这样的重量级产品来对标（话说回来，Apereo CAS 现在自己就支持 OAuth2 来着）。于是市场上的 OAuth2 实现可谓群魔乱舞，槽点一时难以穷尽。

个人建议，在选取 OAuth2 产品时，务必通过 oauth playground 进行测试，以验证协议实现的标准性，避免将来踩坑。而如果需要自己临时起一个 OAuth2 服务做测试的话嘛~~~

是的，搭一个 OAuth 服务器 5 分钟就够了。

是的，Apereo CAS 现在也支持 OAuth2 协议了，所以如果你已经按照 15 分钟部署一个 CAS 服务并对接 Shibboleth-IdP 3.4.6 的路程部署好了 CAS 服务的话，那么只需要略微的调整，就可以让他支持 OAuth2 了，5 分钟足矣。

下文假定已经安装好了 shibboleth-idp-3.4.6 和 cas 6.1 ，并使用 httpd 方式代理发布。

设置好 clientId ， clientSecret ，设置好允许的 serviceId ,也就是 redirect_uri 。

此处默认的值是 NEST ，此时 userinfo 的中，属性部分是带 attributes 的子结构的, 如果是 FLAT 的话，则会去掉结构铺平。以下示例引用自 Apereo CAS 官网

Shibboleth-IdP 的 OAuth2 对接需要去掉结构，所以我们使用 FLAT 模式

如果没有 CAS 部署的前序工作的话，5 分钟的时间可能不太够。但是既然 FLAG 已经立好了。。。我们可以用 oauth-server-lite 来快速的构建一个 oauth 服务。

配置文件的示例。考虑到 5 分钟还是有点紧张，我们只挑重要的部分修改。把 ldap 部分的配置修改为实际的 ldap 参数，把 http->session_options->domain 修改为实际的服务器域名。然后执行 ./control start 运行

其实 3.4.6 之后，由于新版插件均采用标准的 Externel 模式运行，因此 IdP 的 OAuth2 对接和 CAS 对接基本是完全一致的 —— 实际上 OAuth2 插件本来就是在 CAS 插件的基础上改的。有变化的地方仅 2 处。

更多细节可以关注 上海教育认证中心-IdP-Oauth2 对接 中的配置说明。

CC BY-SA

我的博客即将同步至 OSCHINA 社区，这是我的 OSCHINA ID：小冯冯，邀请大家一同入驻： https://www.oschina.net/sharing-plan/apply

与第三方应用对接技术文档，怎么能不知道OAuth2.0？

当前浏览器不支持播放音乐或语音，请在微信或其他浏览器中播放

OAuth是一个关于授权（authorization）的开放网络标准,只要授权方和被授权方遵守这个协议去写代码提供服务，那双方就是实现了OAuth模式。

一、应用场景

如果用户想要使用一个第三方的应用（客户端）来冲洗自己存储在Google的的照片，这个客户端就要得到用户的授权，才可以调用这些照片，传统方法是，用户将自己在Google的用户名和密码，告诉客户端，客户端就可以读取用户的照片了。但是，这样的做法有以下几个严重的缺点：

1. 为了后续的服务，客户端会保存用户的密码，这样很不安全。

2. Google不得不部署密码登录，但单纯的密码登录并不安全。

3. 客户端拥有了获取用户储存在Google所有资料的权力，用户没法限制客户端获得授权的范围和有效期。

4. 用户只有修改密码，才能收回赋予客户端的权力。但这样做会使得其他所有获得用户授权的第三方应用程序全部失效。

5. 只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

有了OAuth的存在，就可以解决上面这些问题了，OAuth的作用就是让"客户端"安全可控地获取"用户"的授权，与"服务商提供商"进行互动。

二、解决方式

OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

三、运行流程

四、客户端的授权模式

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。

• 授权码模式（authorization code）

• 简化模式（implicit）

• 密码模式（resource owner password credentials）

• 客户端模式（client credentials）

今天先来讲解比较主流的两种吧！

（一）授权码模式

是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

下面是上面这些步骤所需要的参数。

A步骤中，客户端申请认证的URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为"code"

• client_id：表示客户端的ID，必选项

• redirect_uri：表示重定向URI，可选项

• scope：表示申请的权限范围，可选项

• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

下面是一个例子。

C步骤中，服务器回应客户端的URI，包含以下参数：

• code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。

• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

下面是一个例子。

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：

• grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。

• code：表示上一步获得的授权码，必选项。

• redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。

• client_id：表示客户端ID，必选项。

下面是一个例子。

E步骤中，认证服务器发送的HTTP回复，包含以下参数：

• access_token：表示访问令牌，必选项。

• token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。

• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。

• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。

• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

下面是一个例子。

从上面代码可以看到，相关参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存。

(二）密码模式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

B步骤中，客户端发出的HTTP请求，包含以下参数：

• grant_type：表示授权类型，此处的值固定为"password"，必选项。

• username：表示用户名，必选项。

• password：表示用户的密码，必选项。

• scope：表示权限范围，可选项。

C步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。

整个过程中，客户端不得保存用户的密码。

五、更新令牌

如果用户访问的时候，客户端的"访问令牌"已经过期，则需要使用"更新令牌"申请一个新的访问令牌。

客户端发出更新令牌的HTTP请求，包含以下参数：

• grant_type：表示使用的授权模式，此处的值固定为"refreshtoken"，必选项。

• refresh_token：表示早前收到的更新令牌，必选项。

• scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。

下面是一个例子。

今天就讲到这里，下期会补充其他的两种方式，敬请期待哦~