【身份安全】OAuth 2.0工作原理（一）

OAuth 授权框架

OAuth 是一个授权框架，它使应用程序能够在 HTTP 服务上获得对用户帐户的有限访问权限。它的工作原理是将用户身份验证委托给托管用户帐户的服务，并授权第三方应用程序访问该用户帐户。OAuth 2 为 Web 和桌面应用程序以及移动设备提供授权流程。

一、OAuth 角色

• 资源拥有者（Resource Owner）
  资源所有者是授权应用程序访问其帐户的用户。应用程序对用户帐户的访问权限仅限于授予的授权范围（例如读取或写入访问权限）。

• 客户端（Client）
  客户端是想要访问用户账户的应用程序。在它可以这样做之前，它必须得到用户的授权，并且授权必须由 API 验证。

• 资源服务器（Resource Server）
  资源服务器托管受保护的用户帐户。

• 授权服务器（Authorization Server）
  授权服务器验证用户的身份，然后向应用程序颁发访问令牌。

从应用程序开发人员的角度来看，服务的 API 既可以充当资源服务器角色，也可以充当授权服务器角色。我们将把这两个角色结合起来称为服务或 API 角色。

二、协议流程

过程步骤：

1. 应用向用户请求访问某服务资源的授权。
2. 用户授权应用的请求，给 [授权许可]。
3. 应用提供自身的 [身份验证] + [授权许可]，请求 [访问令牌]。
4. [身份验证] 通过且 [授权许可] 有效，颁发 [访问令牌]（即 token）。
5. 应用使用 [访问令牌] 请求资源服务器对应的资源。
6. 若 [访问令牌] 有效，允许访问相应资源。
   

三、应用注册（Application Registration）

在将 OAuth 与您的应用程序一起使用之前，您必须向该服务 API（授权服务器 + 资源服务器）注册您的应用程序。这是通过服务网站的开发人员或 API 部分中的注册表格完成的，您将在其中提供以下信息（可能还有关于您的应用程序的详细信息）：

• 应用名称
• 申请网站（资源）
• 重定向 URL（Redirect URI）或回调 URL（Callback URL）

重定向 URI 是服务在用户授权（或拒绝）您的应用程序后重定向用户的位置，因此是您的应用程序将处理授权代码或访问令牌的部分。

用户 ID（Client ID） 和 用户密码（Client Secret）

注册应用程序后，该服务将以客户端标识符和客户端密码的形式颁发客户端凭据。客户端 ID 是一个公开的字符串，服务 API 使用它来识别应用程序，还用于构建提供给用户的授权 URL。Client Secret 用于在应用程序请求访问用户帐户时向服务 API 验证应用程序的身份，并且必须在应用程序和服务 API 之间保密。

四、权限授予

在前面概述的抽象协议流程中，前四个步骤涵盖了获取授权授予和访问令牌。授权授予类型取决于应用程序请求授权所使用的方法，以及 API 支持的授权类型。OAuth 2 定义了三种主要的授权类型，每种类型在不同情况下都有用：

• 授权码：与服务器端应用程序一起使用。
• 客户端凭证：用于具有 API 访问权限的应用程序。
• 设备代码：用于缺少浏览器或有输入限制的设备。

授权类型：授权码

授权码授予类型是最常用的，因为它针对服务器端应用程序进行了优化，其中源代码不公开，并且可以维护 Client Secret 的机密性。这是一个基于重定向的流程，这意味着应用程序必须能够与用户代理（即用户的网络浏览器）交互并接收通过用户代理路由的 API 授权代码。

【授权码】：用户给 APP，用于 APP 向 API server 申请资源访问令牌 token。
【令牌】：就是 token，API server 颁发给 APP，用于 APP 向资源服务器请求资源。

1、授权码链接

首先给用户提供授权码链接：

https://cloud.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

拆解：

• 授权端点：https://cloud.com/v1/oauth/authorize
• 应用程序的客户端 ID：client_id=CLIENT_ID（服务器 API 识别应用程序【知道用户是谁】）
• 重定向 URL：redirect_uri=CALLBACK_URL（服务在被用户授权后重定向 URL user-agent【API server 授权之后知道给谁发消息】）
• 相应类型：response_type=code（指定应用程序正在请求授权码）
• 权限范围：scope=read（指定应用程序访问级别为只读）

Casdoor 示例：

endpoint/login/oauth/authorize?client_id=xxx&response_type=code&redirect_uri=xxx&scope=read&state=xxx

• client_id：用户 ID，可以在多个应用程序 APP 中。
• redirect_uri：应用程序 APP 回调的 URL，通过这个信息，Casdoor 可以知道在授权后向哪里发送信息。
• state：应用程序的名称。

2、用户授权申请

当用户单击该链接时，他们必须首先登录该服务以验证他们的身份（除非他们已经登录）。然后服务会提示他们授权或拒绝应用程序访问他们的帐户。

3、应用程序接收授权码

如果用户单击授权应用程序，该服务会将用户代理重定向到在客户端注册期间指定的应用程序重定向 URI 以及授权代码。重定向看起来像这样（假设应用程序是 dropletbook.com）：

https://dropletbook.com/callback?code=AUTHORIZATION_CODE

4、应用程序请求访问令牌

应用程序通过将授权代码连同身份验证详细信息（包括 client secret）传递到 API 令牌端点，从 API 请求访问令牌。

示例请求：

https://cloud.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

5、应用程序接收访问令牌

如果授权有效，API 将向应用程序发送包含访问令牌（以及可选的刷新令牌）的响应。整个响应看起来像这样：

{
    "access_token": "ACCESS_TOKEN",
    "token_type": "bearer",
    "expires_in": 2592000,
    "refresh_token": "REFRESH_TOKEN", // 用于请求新的令牌
    "scope": "read",
    "uid": 100101,
    "info": {
        "name": "Mark E. Mark",
        "email": "mark@thefunkybunch.com"
    }
}

现在该应用程序已获得授权。它可以使用令牌通过服务 API 访问用户的帐户，仅限于访问范围，直到令牌过期或被撤销。如果发布了刷新令牌，如果原始令牌已过期，则可以使用它来请求新的访问令牌。

五、Casdoor 运行原理

1、应用向用户请求授权

endpoint/login/oauth/authorize?client_id=xxx&response_type=code&redirect_uri=xxx&scope=read&state=xxx

• client_id：用户 ID，可以在多个应用程序 APP 中。
• redirect_uri：应用程序 APP 回调的 URL，通过这个信息，Casdoor 可以知道在授权后向哪里发送信息。
• state：应用程序的名称。

应用程序对用户说：

“嘿，现在我需要一些资源，我需要您的许可才能拿这些资源。您愿意跳转到这个 URL，填写您的用户名和密码吗？”

使用正确的 URL，您的应用程序将会让用户向此 URL 发起请求，授权请求已完成。

2、用户给应用授权

此步骤比较直接：用户会被重定向到上面的 URL，看到来自 Casdoor 的登录页面。通过在登录页面输入正确的用户名和认证信息，Casdoor 现在能成功识别用户，将发送 code 和 state 返回第 1 步中设置的回调 URL。

“用户打开网址并向 Casdoor 提供凭据。Casdoor 说：‘好~ 这是我在数据库中知道的用户（授权应用获取 code 和 state）。然后我将使用回调 URL 发送 code 和 state 返回应用（redirect_uri）。’”

3、API server 验证 APP 的授权认证

在这一步，您的应用程序已经有了来自第 2 步的代码，它将会告诉 Casdoor：

“嘿，现在用户同意给我 code，你想检查这个 code 并给我 access_token 吗？”

4、API server 给 APP 颁发令牌

在这一步，Casdoor 会通知应用程序：

“这个 code 应该是合法的，你一定就是那个正确的应用程序。这是 access_token。”

5、APP 用令牌给资源服务器验证

在这个步骤中，您的应用程序说：

“很好，刚刚获得了最新的 access_token，我现在可以使用它从资源服务器获得更多宝贵的东西！”

您的应用程序转向资源服务器：

“嗨朋友，想检查这个 access_token 吗？我从 Casdoor 得到了访问令牌，你想看看这是否与 Casdoor 的一致吗？”

6、APP 使用令牌访问资源服务器资源

资源服务器又告知您的应用程序：

“不错~ 它似乎就像我在 Casdoor 中的那个一样。Casdoor 说谁拥有这个 access_token 谁就可以拥有这些受保护的资源。现在，你可以自取这些资源了！”

这就是 Casdoor 如何与您的应用程序一起工作。

回调网址

SSO 登录成功之后会传信息的网址，会传递 code 和应用名称。

拿到 code 向 SSO 的 API 请求获得 access_token【后面就用 access_token 放到用户的 cookie 中使用】。

代码

后端代码

前端代码

by 久违