OAuth 2.0

核心角色

OAuth 2.0 协议中定义了以下角色：

• 资源所有者 (resource owner): 简单理解就是我们终端用户
• 资源服务器 (resource server): 终端用户的资源服务器
• 客户端 (client): 代表资源所有者发起请求的应用
• 授权服务器(authorization server): 在资源所有者进行鉴权之后，颁发令牌的服务器

主体流程

客户端作为一个接入方，首先获取用户的授权，拿到用户授权以后，在向授权服务器请求获取 access token ，拿到 token 以后，我们就能正常获取资源服务器中被授权的内容了

授权模式

授权码模式 (Authorization Code)

OAuth 流程

• A: Client 通过将浏览器的请求发送到 Authorization Server 来发起流程，请求中包括了授权码申请的请求参数
• B: Authorization Server 进行身份验证
• C: 授权通过以后，会返回 Authorization code
• D: Client 带着授权码以及重定向 URI 获取 token
• E：Authorization Server校验通过以后,会返回 AccessToken

参数说明

Authorization Request

Authorization Response

Access Token Request

Access Token Response

Access Token Response 通常是以 json 格式进行返回

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

HTTP/1.1 200 OK
    Content-Type: application/json;charset=UTF-8
    Cache-Control: no-store
    Pragma: no-cache

   {
      "access_token":"2YotnFZFEjr1zCsicMWpAA",
      "token_type":"example",
      "expires_in":3600,
      "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
      "example_parameter":"example_value"
   }

token_type 说明

• Bearer 类型的 Token 可以直接请求资源

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM

• mac 类型需要在颁发访问令牌的同时提供一个消息认证码（MAC）密钥，用于对 HTTP 请求的某些部分进行签名

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
                 nonce="274312:dj83hs9s",
                 mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

隐式授权模式(Implicit Grant)

授权流程

参数说明

由于简化了交互流程，所以在 /authorize 端点就会返回 token ，所以请求字段没有变化，返回字段也基本没有大的改变，知识返回方式有一些变化

Authorization Request

Authorization Response

隐式授权存在一些安全隐患，标准的 Response 是以 URL fragment 形式返回参数既在重定向的地址后面通过#key1=val1&key2=val2 的形式返回，在浏览器端，JS 是可是劫持到fragment的内容以获取到 access_token

密码模式(Password Credentials)

适用场景很少，一般仅信任的客户端使用（如自家 App）。

客户端凭证(Client Credentials)

服务端到服务端通信。

实践场景说明

最近在研究 Odoo 的自定义 OAuth Provider ,所以就以 Odoo 的登录与交互流程来举例吧

Odoo 可能是为了快速兼容多中 OAuth Provider ，所以他的登录流程是基于 Implicit 模式的，但是不影响我们理解

%%{init: {'theme':'neutral'}}%%
sequenceDiagram

actor Browser as Browser

participant OAuthClient as Odoo

participant OAuthProvider as Keycloak(Authorization Server)

Browser ->> OAuthClient: GET https://odoo.local/signin
OAuthClient ->> Browser: 返回登录页面

Browser ->> OAuthClient: 选择 OAuth 登录

OAuthClient ->> Browser: HTTP 302 <br>location https://keycloak.local/login?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URI

Browser ->> OAuthProvider: GET https://keycloak.local/login?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URI

OAuthProvider ->> Browser: HTTP 200 <br> /login.html

Browser --> OAuthProvider: POST /login with oauth parameter

OAuthProvider ->> Browser: HTTP 302 <br>location CALLBACK_URI?#access_token=token&

Browser ->> OAuthClient: 从地址栏解析 access_token
OAuthClient ->> OAuthProvider: Access Resources with Access Token

Note right of OAuthClient: 下面的为一个使用示例
OAuthClient -->> OAuthProvider: POST /openid-connect/userinfo/uid <br> Authorization: Bearer xxx.yyy.zzz
OAuthProvider -->> OAuthClient: 返回用户信息
OAuthClient -->> OAuthClient: 注册/更新用户信息
OAuthClient -->> Browser: Set Odoo own session cookie

Token 与 JWT

其实 OAuth 协议中对于 access_token 的值没有做限制，理论上来说任何满足要的的字符串都可以作为 access_token 使用，比如一个 1,只要 Authorization Server 能通过鉴权,那么1 也可以作为 access_token 使用，但是主流实现(Auth0,Keycloak,Google)，基本都会颁发 JWT 格式的 access_token

JWT 的 Token 属于标准的三段式 xxx(Header).yyy(Playload).zzz(Signature) 中间以 . 分隔，每段都进行了 base64 编码,其中第三段为签名段，验签的时候需要使用。

比如下面的这段 token

我们可以对 Header 与 Playload 段进行解码

Header 解码

1
2
3
4
5

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "73AZgfMvbINHxZuQ3yCNix2N9nqHglE6P0C6U7qgUU8"
}

Payload 解码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

{
  "exp": 1745302626,
  "iat": 1745301726,
  "auth_time": 1745301726,
  "jti": "onrtna:419a71b6-b0e7-4078-9e2a-8f0d46444058",
  "iss": "http://keycloak.local:8080/realms/beem",
  "aud": "account",
  "sub": "706470bb-677b-4247-9c77-19f5bba4b067",
  "typ": "Bearer",
  "azp": "odoo",
  "sid": "08dda9bc-ee6a-4805-b839-00c04acb6bd5",
  "acr": "1",
  "allowed-origins": [
    "http://odoo.local:8069"
  ],
  "realm_access": {
    "roles": [
      "default-roles-beem",
      "offline_access",
      "uma_authorization"
    ]
  },
  "resource_access": {
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "scope": "openid profile email",
  "email_verified": true,
  "name": "Zhang Yang",
  "preferred_username": "zhangyang",
  "given_name": "Zhang",
  "family_name": "Yang",
  "email": "zhangyang911120@outlook.com"
}

OAuth2.0 与 OIDC

如果要兼容 OIDC 协议，需要在 access_token 的基础上，颁发 JWT 格式的 id_token 并包含 OIDC 标准的兼容字段

OAuth 与 SSO

SSO（单点登录）和OAuth 2.0在身份认证和授权方面各有特点，理解它们的区别和联系有助于在实际应用中做出合适的选择。

1. SSO（单点登录）：

• 定义：SSO是一种机制，允许用户在多个应用或系统中只需登录一次，即可访问所有相互信任的应用，无需重复登录。
• 应用场景：适用于企业内部有多个相互关联的系统，用户需要在不同系统间频繁切换的场景。
• 工作原理：用户在SSO认证系统中登录后，系统会生成一个全局会话或令牌，用户在访问其他应用时，应用通过验证该会话或令牌来确认用户身份，从而实现免登录访问。

2. OAuth 2.0：

• 定义：OAuth 2.0是一个授权框架，允许第三方应用在用户授权的情况下，访问用户在服务提供商处的特定资源，而无需直接提供用户名和密码。
• 应用场景：适用于需要授权第三方应用访问用户资源的场景，如使用微信登录其他应用。
• 工作原理：用户授权第三方应用访问其资源后，授权服务器颁发访问令牌（Access Token）给第三方应用，应用持此令牌访问资源服务器上的用户数据。 区别与联系：
• 关注点不同：SSO关注用户在多个系统间的认证过程，旨在提供无缝的登录体验；OAuth 2.0关注授权过程，旨在安全地授权第三方应用访问用户资源。
• 应用场景不同：SSO主要用于企业内部系统的整合，解决用户在多个内部应用间的认证问题；OAuth 2.0主要用于第三方应用的授权访问，如社交媒体登录等。

参考资料