您现在的位置 :

首页  >  行业动态 >  > 正文

OIDC & OAuth2.0 认证协议最佳实践系列 02 - 授权码模式接入 Authing

时间 :2023-07-08 11:48:42   来源 : 哔哩哔哩

在上一篇文章中，我们整体介绍 OIDC / 协议（ 点击下方图片即可查看 ），本次我们将重点围绕授权码模式（Authorization Code）以及接入 Authing 进行介绍，从而让你的系统快速具备接入用户认证的标准体系。

接入 Authing 后的优势：


(资料图)

在整个 Authing 的身份源中，已经包含了社会化登录方式 微信、微博、QQ、FB、TW ...等等，企业登录方式 飞书、钉钉、企微、AD 等等，只要你完成了接入 Authing 就意味着你的业务系统具备了这些能力。

01.授权码模式（Authorization Code）

授权码模式适合应用具备后端服务器的场景。授权码模式要求应用必须能够安全存储密钥，用于后续使用授权码换 access_token。授权码模式需要通过浏览器与终端用户交互完成认证授权，然后通过浏览器重定向将授权码发送到后端服务，之后进行授权码换 token 以及 token 换用户信息。

整体流程

整体上，有以下流程：

1. 在你的应用中，让用户访问登录链接，浏览器跳转到 Authing，用户在 Authing 完成认证。

2. 浏览器接收到一个从 Authing 服务器发来的授权码。

3. 浏览器通过重定向将授权码发送到你的应用后端。

4. 你的应用服务将授权码发送到 Authing 获取 AccessToken 和 IdToken，如果需要，还会返回 refresh token。

5. 你的应用后端现在知道了用户的身份，后续可以保存用户信息，重定向到前端其他页面，使用 AccessToken 调用资源方的其他 API 等等。

流程图如下：

准备接入

在 Authing 创建应用及配置

创建应用：

配置登录回调和登出回调，配置为你实际项目的地址，我们在这里配置 localhost 用于测试。

若你想匹配多个登录/登出回调，可以使用 ‘*’ 号进行通配，登录/登出回调可以是如下格式：

在协议配置中，我们勾选 authorization_code 并且使用 code 作为返回类型，如下图所示：

接入测试

01 所需调用接口列表

GET${host}/oidc/auth 发起登录（拼接你的发起登录地址）

POST${host}/oidc/token 获取 Token

GET${host}/oidc/me 获取用户信息

POST${host}/oidc/token/introspection 校验 Token

POST${host}/oidc/token 刷新 Token

POST${host}/oidc/revocation 吊销 Token

GET${host}/session/end 登出

02 Run in Postman

以下要介绍的接口可以通过我们的在线 postman collection 自行 fork 体验。

03 发起登录

这是基于浏览器的 OIDC 的起点，请求对用户进行身份验证，并会在验证成功后返回授权码到您所指定的 redirect_uri。

拼接发起登录地址（浏览器中打开）：

https://{host}/oidc/auth?scope=openid+profile+email+phone+username&redirect_uri={redirect_uri}&response_type=code&client_id={应用 ID}&state={state}

如您需要额外获取 refresh_token 则请求格式为：

https://{host}/oidc/auth?

scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&client_id={应用 ID}&prompt=consent&state={state}

点此体验：

/oidc/auth?scope=openid+profile+offline_access+username+email+phone&redirect_uri=http://localhost:8080/&response_type=code&prompt=consent&nonce=054d3c0e-9df9-46f2-a8fa-a7f479032660&client_id=63eb4585156d977101dd3750&state=1676366724

参数说明：

04 获取 Token

用户在 Authing 侧完成登录操作后， Authing 会将生成的 code 作为参数回调到 redirect_uri 地址，此时通过 code 换 token 接口即可拿到对应的访问令牌 access_token 。

1. 请求参数

2. 请求事例

3. 响应示例 (成功)

4. 响应示例 (失败)

05 通过 AccessToken 获取用户信息

此端点是 OIDC 获取用户端点，可以通过 AccessToken 获取有关当前登录用户的信息。

1. 请求参数

2. 请求示例

3. 响应示例 (成功)

4. 响应示例 (失败)

06 校验 Token

此端点接受 access_token、id_token、refresh_token ，并返回一个布尔值，指示它是否处于活动状态。如果令牌处于活动状态，还将返回有关令牌的其他数据。如果 token 无效、过期或被吊销，则认为它处于非活动状态。

1. 验证 Token 分为两种方式：

本地验证与使用 Authing 在线验证。我们建议在本地验证 JWT Token，因为可以节省你的服务器带宽并加快验证速度。你也可以选择将 Token 发送到 Authing 的验证接口由 Authing 进行验证并返回结果，但这样会造成网络延迟，而且在网络拥塞时可能会有慢速请求。

access_token 可以使用 RS256 签名算法或 HS256 签名算法进行签名。下面是这两种签名算法的区别：

RS256 是使用RSA算法的一种数字签名算法，它使用公钥/私钥对来加密和验证信息。RS256 签名生成的令牌比 HS256 签名生成的令牌更加安全，因为使用RSA密钥对进行签名可以提供更高的保护级别。使用RS256签名算法的令牌可以使用公钥进行验证，公钥可以通过 JWK 端点获取。

HS256 是使用对称密钥的一种数字签名算法。它使用同一个密钥进行签名和验证。HS256 签名算法在性能方面比 RS256 签名算法更快，因为它使用的是对称密钥，而不是使用 RSA 公钥/私钥对来签名和验证。使用 HS256签名算法的令牌可以通过 shared secret （应用密钥）进行验证。

在实际应用中，RS256算法更加安全，但同时也更加消耗资源，如果系统需要高性能，可以选择 HS256 签名算法。

以下是本地验证和在线验证的优劣对比：

2. 在线验证

需要注意的是，id_token 目前无法在线校验，因为 id_token 只是一个标识，若需要校验 id_token 则需要您在离线自行校验。

请求参数

请求示例

校验 access_token 响应示例（校验通过）

校验 access_token 响应示例（校验未通过）

校验 refresh_token 响应示例 (校验通过)

校验 refresh_token 响应示例（校验未通过）

3. 离线校验

可参考文档：离线校验

文档链接：/v2/guides/faqs/#

我们简单说下，若您使用离线校验应该对 token 进行如下规则的校验：

1. 格式校验 - 校验 token 格式是否是 JWT 格式

2. 类型校验 - 校验 token 是否是目标 token 类型，比如 access_token 、id_token、refresh_token

3. issuer 校验 - 校验 token 是否为信赖的 issuer 颁发

4. 签名校验 - 校验 token 签名是否由 issuer 签发，防止伪造

5. 时间校验 - 校验 token 是否在有效期内

6. claims 校验 - 是否符合与预期的一致

以上 6 点均校验通过，我们才能认为 token 是有效且合法的。

下面是一个示例 Java 代码，可以用于在本地校验 OIDC RS256 和 HS256 签发的 access_token 。

这段代码使用 Nimbus JOSE+JWT 库来解析和验证 JWT token。它使用指定的 issuer 和 audience 值对access_token 进行验证，并验证 JWT 中 claims 的格式、类型、签名、有效期和 issuer。如果发生任何验证错误，则将抛出 RuntimeException。使用时需要传入对应的 JWK URL 和 access_token 进行调用，例如：

这个示例只校验了RS256和HS256签名算法。

07 刷新 Token

此功能用于用户 token 的刷新操作，在 token 获取阶段需要先获取到 refresh_token 。

1. 请求参数

2. 请求示例

3. 响应示例(成功)

4. 响应示例（失败）

08 撤回 Token

撤销 access_token / refresh_token 

1. 请求参数

2. 请求示例

3. 响应示例（成功）

4. 响应示例（失败）

09 用户登出

使用此操作通过删除用户的浏览器会话来注销用户。

post_logout_redirect_uri 可以指定在执行注销后重定向的地址。否则，浏览器将重定向到默认页面

1. 请求参数

2. 请求示例 (浏览器访问)

02.SSO (Single Sign-On)  单点登录 & SLO (Single Logout) 单点登出

 SSO 实现

SSO(Single Sign-On) 单点登录，即同时访问多个应用仅需要登录一次。

举例：我们现在有两个站点分别是

 

 

我们希望用户在 进行认证后，跳转到 ething 后无需二次认证，反之也是一样的。

具体流程：

1. 用户访问 ，uthing 前端发现用户未认证，跳转至 Authing 进行认证。

2. 用户在 Authing 发起认证完成，Authing 创建 SSO Session ，下发临时授权码 (code) 重定向到 uthing 后台。

需要注意的是，在这里我们也可以重定向到前端页面，再由前端页面自行判断如果是 Authing 回调请求，则携带临时 code 到 uthing 后台去获取 token 。

3. uthing 后台通过 code 向 Authing 换取 access_token、id_token、refresh_token 等，并下发给前端。

4. uthing 前端通过 access_token 可以直接向 Authing OIDC 用户信息端点获取当前用户信息。

5. uthing 前端在在后续请求后台时，携带由 Authing 颁发的 access_token ，后台在接受到用户请求后去 Authing 校验 Token 是否有效，有效则可放行，若 Token 校验失败或已过期则返回错误信息。

6. 用户访问 ，ething 跳转至 Authing 进行认证。

7. 由于用户在 Authing 已经完成认证，创建了 sso_session ，Authing 侧直接下发临时授权码 (code) ，无需二次认证，后续流程同 1 。

 

我们发现，用户在 uthing 认证成功的时候，再访问 ething 的时候会向 Authing 跳转一下，才能完成后续流程，这是由于 和 并不是同一个站点，无法实现 cookie 共享，如果你的产品地址是 ：

 

 

我们则可以利用相同域下 cookie 共享的方式实现 SSO ，从而避免此问题。

 SLO 实现

SLO(Single Logout) 单点登出，即多个应用仅需要登出一次，其他应用也自动登出 。

01 场景 1

如果你的产品地址是同一个域，例如：

 

则 SLO 流程如下：

1. 用户在某个站点登出，我们则需要调用 OIDC 登出端点销毁 Token，由于是 cookie 共享实现的 SSO ，然后清除 对应会话的 cookie 即可。

2. ething / uting 应当在每次发起请求前，判断 cookie 中是否存在登录态，若不存在，则需要跳转默认页面提示用户已经登出。

02 场景 2

如果你的产品地址不是同一个域，例如：

 

则 SLO 流程如下：

1. 用户在某个站点登出，我们则需要调用 OIDC 登出端点销毁 Token，在 Authing 的应用配置中，你应当先把应用都添加到 SSO 中，或者 和 使用 Authing 的同一个自建应用，当用户在某个站点登出后，另外一个站点的 Token 也会失效。

2. 用户未登出的站点发起请求，当后台校验 Token 失败后，则下发清除 cookie 的命令并跳转默认页面提示用户已经登出，需要登录。

03.本章总结

本章我们介绍了 OIDC 授权码模式的接入流程以及相关接口的调用方式，对于小白来说可能需要整体跑一遍流程才能熟悉，我们也建议你 fork 我们的 postman collection 跑一遍流程，对授权码模式你就基本掌握啦。

接下来我们还会介绍 OIDC 的授权码+PKCE 流程，以及接入 Authing 的方式，需要你对授权码模式的流程有一定了解哦。

标签：

推荐文章

X 关闭

资讯

X 关闭

行业动态