同源策略（Same-Origin Policy）

最新推荐文章于 2025-03-17 16:05:09 发布

Hopebearer_

最新推荐文章于 2025-03-17 16:05:09 发布

阅读量2.7k

点赞数 40

分类专栏： ajax 文章标签： javascript 开发语言网络协议网络

本文链接：https://blog.youkuaiyun.com/qq_74114417/article/details/144475186

版权

ajax 专栏收录该内容

3 篇文章

订阅专栏

同源策略（Same-Origin Policy）

1. 什么是同源策略？

同源策略是Web浏览器的一种安全机制，用于限制来自不同源的文档或脚本如何与另一个源的资源进行交互。

这种策略有助于防止恶意网站读取另一个网站的敏感数据，例如用户的登录凭据或私人信息。通过确保只有来自相同源的脚本才能访问和操作DOM、发送AJAX请求或读取Cookie等，同源策略为Web应用程序提供了基本的安全保障。

2. 源（origin）

1. 定义

Web内容的源由用于访问它的URL的方案（协议）、主机名（域名）和端口定义。即源由协议、域名和端口组成。

2. 组成

协议（Protocol）： 资源使用的传输协议，如http、https、ftp等。
域名（Domain Name）： 资源的网络域名。例如example.com、other-example.com 这包括了主域名以及可能存在的子域名，如www.example.com和mail.example.com会被视为不同的子域名，除非特别配置为同源。
端口（Port）： 资源服务器监听的端口号，如80（http默认端口）或443（https默认端口）。如果端口号没有显式指定，则浏览器会使用协议的默认端口。

3. 同源

只有当两个资源的协议、域名和端口都完全相同时，它们才被认为是同源的。例如(下方URL均与http://example.com/dir/index.html比较)：

URL	是否同源	原因
http://example.com/dir2/index.html	同源	只有路径不同，协议、域名和端口均相同
https://example.com/dir/index.html	不同源	协议不同
http://example.com:81/dir/index.html	不同源	端口不同
http://example.org/dir/index.html	不同源	主机不同（域名不同）

4. 源的继承

1. 定义与解释

在页面中通过 about:blank 或 javascript:； URL 执行的脚本会继承打开当前 URL 的文档的源，因为这些类型的 URL 没有包含源服务器的相关信息。接下来对这句话进行逐步解释：

about:blank和javascript:; URL

aboutL:blank是一个特殊的URL，用于创建一个空白页面。当你在浏览器地址栏中，输入aboutL:blank或通过脚本打开它时，浏览器会显示一个空白的页面，这个页面没有加载任何内容。
javascript:;URL是一种直接在URL中嵌入JavaScript代码的方式。当你在浏览器地址栏中输入javascript:document.write('hello');，浏览器会执行这段JavaScript代码。

继承打开该URL的文档的源

当你通过 about:blank 或 javascript: URL 执行脚本时，这些脚本实际上是在当前文档的上下文中执行的，而不是在一个新的、独立的上下文中。这意味着这些脚本会继承打开它们的文档的源信息。
例如，如果你在一个来自https://example.com的页面上点击一个链接，该链接的 href 是 javascript:alert(document.domain);，弹出的对话框会显示 example.com，因为脚本是在 https://example.com 的上下文中执行的。
没有包含源服务器的相关信息
about:blank 和 javascript: URL 都不包含指向任何具体服务器的信息。它们不指定一个服务器上的资源，而是直接在浏览器中执行某些操作（显示空白页面或执行JavaScript代码）。
因此，当通过这些类型的URL执行脚本时，浏览器会使用当前文档的源作为脚本执行的源。
对同源策略的影响
由于这些脚本继承了打开它们的文档的源，它们在与该文档同源的其他资源交互时不会受到同源策略的限制。然而，如果它们尝试访问不同源的资源，仍然会受到同源策略的限制。

2. 案例

下面通过一个案例来加深体会：
场景描述
假设有一个网页位于http://example.com，该网页中通过Window.open()方法打开了一个新的空白窗口，窗口的URL被设置为about:blank。然后，这个新窗口通过执行一段JavaScript代码来加载内容。
继承过程

新窗口的初始化： 由于新窗口的URL被设置为about:blank ，这个URL本身不包含原服务器的相关信息。因此，在初始窗台下，新窗口没有自己的源。
脚本的源继承： 当新窗口通过执行JavaScript 代码来加载内容时，这段脚本的源会被自动设置为打开该窗口的文档的源，即http://example.com。这是因为about:blank URL执行的脚本会继承打开该URL的文档的源。
后续操作的影响： 由于新窗口中的脚本继承了http://example.com 的源，因此这个脚本将能够访问与http://example.com 同源的资源，但无法访问不同源的资源。例如，他可以使用AJAX请求访问http://example.com上的数据,但无法访问http://other-example.com上的数据，除非后者明确允许跨域请求。

<!-- `http://example.com/index.html` -->
<!DOCTYPE html>
<html>
    <head>
        <title>源代码继承示例</title>
        <script>
            function openBlankWindow() {
                var newWindow = window.open('about:blank', '_blank');
                newWindow.document.write('<script>alert("这个脚本的源代码继承自 http://example.com");<\/script>');
            }
        </script>
    </head>
    <body>
        <button onclick="openBlankWindow()">Open Blank Window</button>
    </body>
</html>

在这个示例中，当用户点击按钮时，会打开一个新的空白窗口，并在这个窗口中执行一段JavaScript代码。这段代码会弹出一个警告框，显示脚本的源是继承自http://example.com。

注意事项

源的继承只适用于某些特殊URL（如about:blank、javascript:等）或特定情况下脚本的源确定。
在实际开发中，需要注意同源策略的限制，并采取相应的措施来实现跨域交互。！
浏览器对于同源策略的实现可能有所不同，因此在实际应用中需要进行充分的测试。

5. 文件源

现代浏览器通常将使用 file:/// 模式加载的文件的来源视为不透明的来源。这意味着，假如一个文件包括来自同一文件夹的其他文件，它们不会被认为来自同一来源，并可能引发 CORS 错误。

6. 源的更改

1. 原因

跨域资源共享（CORS）需求
在某些情况下，Web应用需要从不同源的服务器获取资源。例如，一个网站可能希望嵌入另一个网站的图片或脚本。由于同源策略的限制，这些跨域请求通常会被浏览器阻止。为了解决这个问题，服务器可以设置CORS头部，允许来自特定源的请求访问其资源。然而，这仍然需要在客户端进行源的更改，以便浏览器能够识别并处理这些跨域请求。
跨域通信需求
在某些情况下，不同源的网页之间需要进行通信。例如，一个父页面可能包含多个不同源的iframe，并且这些iframe之间需要交换数据。为了实现跨域通信，可以使用window.postMessage等方法。然而，这同样需要在客户端进行源的更改，以便浏览器能够识别并处理这些跨域消息。
解决开发中的特殊需求
在开发过程中，可能会遇到一些特殊需求，如需要在本地环境中测试跨域请求或通信。此时，可以通过更改源的方式来绕过同源策略的限制，以便进行开发和测试。

2. 方法

设置document.domain属性

document.domain属性允许页面在一定限制下更改自己的源。具体来说，脚本可以将document.domain的值设置为当前域或其当前域的超域。如果设置为当前域的超域，将使用更短的超域进行同源检查。
例如，来自http://store.company.com/dir/other.html的文档的脚本可以执行document.domain = "company.com";，之后该页面可以与http://company.com/dir/page.html进行同源检查（前提是后者也将其document.domain设置为company.com）。

注意：源的更改通常是通过设置document.domain属性来实现的。然而，这种方法已经被弃用，因为它破坏了同源策略提供的安全保护，并且可能导致互操作性问题和安全漏洞。现代浏览器通常不允许直接更改源的协议或端口部分，而只能对域名进行一定的限制和修改。因此这种方法只做了解。

7. 跨域网络访问

同源策略控制不同源之间的交互，例如在使用XMLHttpRequest或<img>标签时则会受到同源策略的约束。这些交互通常分为三类：

跨源写操作（Cross-origin writes）: 一般是被允许的。例如链接、重定向以及表单提交。特定少数的HTTP请求需要添加预检请求。
跨源资源嵌入（Cross-origin embedding): 一般是被允许的（后面会举例说明）。
跨源读操作（Cross-origin reads）: 一般是不被允许的，但常可以通过内嵌资源来巧妙的进行读取访问。例如，你可以读取嵌入图片的高度和宽度，调用内嵌脚本的方法，或得知内嵌资源的可用性。

以下是一些可能嵌入跨源的资源示例：

<script>标签嵌入跨域脚本
使用<script src="">标签可以加载并执行来自不同源的JavaScript文件。这是跨域资源嵌入中最常见的方式之一。
<link>标签嵌入CSS
通过<link rel="stylesheet" href="...">标签可以加载来自不同源的CSS样式表。由于CSS的松散语法规则，CSS的跨域访问通常需要服务器设置正确的Content-Type头部。
<img>标签嵌入图片
使用<video>和<audio>标签可以加载和播放来自不同源的音频和视频文件。这允许网页嵌入跨域的多媒体内容，丰富用户体验。
<object>、<embed>和<applet>标签嵌入插件
这些标签可以用于嵌入来自不同源的Java Applets、Flash、PDF文件等插件内容。不过，随着技术的发展，一些旧的插件技术（如Flash）已逐渐被淘汰。
@font-size引入的字体
使用@font-face规则可以在网页中引入来自不同源的自定义字体。一些浏览器允许跨域字体，而一些浏览器则需要字体文件与网页同源。
<iframe>载入的任何资源
通过<iframe>标签可以加载来自不同源的整个网页或应用。这允许网页嵌入跨域的独立内容区域，但需要注意安全性和性能问题。站点可以使用X-Frame-Options消息头来阻止这种形式的跨域交互。

8. 跨域访问的方法

允许跨域访问通常涉及在服务器端进行相应的配置，以确保浏览器能够安全地访问不同源的资源。以下是一些常见的方法来实现跨域访问：

1. 跨域资源共享(CORS)

CORS（Cross-Origin Resource Sharing）是一种W3C标准，允许服务器通过发送额外的HTTP头部字段来告知浏览器哪些源可以访问其资源。以下是实现CORS的基本步骤：

服务器配置：

在服务器端配置CORS响应头。这通常涉及在HTTP响应中添加Access-Control-Allow-Origin头部字段，以指定哪些源可以访问该资源。
如果需要支持带凭据的请求（如Cookie），还需添加Access-Control-Allow-Credentials头部字段，并将其值设置为true。
对于复杂请求（如使用非简单HTTP方法或自定义头部字段的请求），服务器还需要处理预检请求（OPTIONS请求），并在响应中添加Access-Control-Allow-Methods和Access-Control-Allow-Headers等头部字段。

浏览器处理：

浏览器在发送跨域请求时，会自动添加Origin头部字段，以告知服务器请求的来源。
浏览器会根据服务器的CORS响应头来决定是否允许跨域访问。如果服务器配置了正确的CORS头部字段，并且允许当前源的访问，则浏览器会允许跨域请求和响应；否则，浏览器会阻止跨域请求或响应。

案例：

以Node.js和Express为例

如果使用Node.js和Express框架，可以使用cors 中间件来简化CORS配置。以下是一个基本的配置示例：

const express = require("express");
const cors = require("cors");

const app = express();

//配置CORS中间件
const corsOpitons = {
    //允许https://example.com访问
    origin:"https://example.com",
    //允许发送Cookie
    credentials:true,
    //允许的HTTP方法
    methods:"GET,HEAD,PUT,PATCH,POST,DELETE",
    //允许的自定义头部字段
    allowedHeaders:["Content-Type","Authorization"],
};

app.use(cors(corsOptions));
//你的路由和中间件...

app.listen(3000,()=>{
    console.log("Server is running on port 3000");
});

在这个示例中，cors中间件会根据corsOptions配置来处理CORS请求。origin字段指定了允许访问的源，credentials字段设置为true以允许带凭据的请求，methods字段列出了允许的HTTP方法，allowedHeaders字段列出了允许的自定义头部字段。

示例：使用Apache服务器

如果你正在使用Apache服务器，你可以通过修改.htaccess文件或服务器配置文件来添加CORS响应头。以下是一个.htaccess文件的配置示例：

# 允许所有源访问（不推荐在生产环境中使用）
Header set Access-Control-Allow-Origin "*"

# 允许特定的源访问
# Header set Access-Control-Allow-Origin "https://example.com"

# 允许带凭据的请求
Header set Access-Control-Allow-Credentials "true"

# 允许的方法
Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"

# 允许的头部字段
Header set Access-Control-Allow-Headers "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization"

# 对于复杂请求，处理预检请求（OPTIONS请求）
<LimitExcept GET POST PUT DELETE>
Allow from all
</LimitExcept>

在这个示例中，Header set指令用于添加CORS响应头。你需要根据你的需求调整Access-Control-Allow-Origin、Access-Control-Allow-Methods和Access-Control-Allow-Headers的值。

示例：使用Nginx服务器

如果你正在使用Nginx服务器，你可以在Nginx配置文件中添加CORS响应头。以下是一个配置示例：

server {
    # ... 其他配置 ...

    location / {
        # 允许所有源访问（不推荐在生产环境中使用）
        add_header 'Access-Control-Allow-Origin' '*';

        # 允许特定的源访问
        # add_header 'Access-Control-Allow-Origin' 'https://example.com';

        # 允许带凭据的请求
        add_header 'Access-Control-Allow-Credentials' 'true';

        # 允许的方法
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';

        # 允许的头部字段
        add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

        # ... 其他配置 ...
    }

    # ... 其他配置 ...
}

在这个示例中，add_header指令用于添加CORS响应头。你需要根据你的需求调整这些头部字段的值。请注意，在生产环境中，通常不建议将Access-Control-Allow-Origin设置为*，因为这允许任何源都可以访问你的资源。相反，你应该将其设置为特定的源或使用其他安全措施来限制访问。

2. JSONP（JSON with Padding）

JSONP是一种利用<script>标签不受同源策略限制的特性来实现跨域访问的方法。以下是使用JSONP的基本步骤：

客户端请求：
客户端通过动态创建一个<script>标签，并将其<src>属性设置为跨域请求的URL。URL中通常包含一个回调函数名作为查询参数。
服务器端响应：
服务器接收到请求后，将相应数据作为回调函数的参数包裹在一个JavaScript函数中，并返回给客户端。
客户端处理：
当<script>标签被加载时，浏览器会执行返回的JavaScript函数，从而调用客户端定义的回调函数，并将响应数据作为参数传递给该函数。

3. 代理服务器

代理服务器是一种在客户端和目标服务器之间转发请求和响应的中间层。通过配置代理服务器，可以实现跨域访问，而无需在服务器端进行CORS配置。以下是使用代理服务器的基本步骤：

配置代理服务器：

选择一个合适的代理服务器软件（如Nginx、Apache、Node.js等），并进行相应的配置。
在代理服务器中设置转发规则，将来自客户端的跨域请求转发到目标服务器，并将目标服务器的响应返回给客户端。

客户端请求：

客户端将请求发送到代理服务器，而不是直接发送到目标服务器。

代理服务器转发请求：

代理服务器接收到请求后，将其转发到目标服务器。

代理服务器返回响应：

目标服务器将响应发送给代理服务器，代理服务器再将相应返回给客户端。

4. 其他方法

除了上述三种常见方法外，还有其他一些方法可以实现跨域访问，如：

WebSocket： WebSocket是一种在单个TCP连接上进行全双工通信的协议，不受同源策略限制。通过WebSocket可以实现跨域通信。
postMessage： HTML5引入的postMessage API允许跨窗口通信，不论这两个窗口是否同源。

需要注意的是，不同的方法适用于不同的场景和需求。在选择跨域访问的实现方法时，需要根据具体情况进行权衡和选择。同时，还需要注意数据的安全性和隐私保护问题。

9. 拒绝跨域访问的方法

拒绝跨域访问通常是为了增强服务器的安全性，防止未授权的访问和数据泄露。以下是一些常见的方法来实现拒绝跨域访问：

1. CORS配置

CORS（跨源资源共享）是一种机制，通过配置CORS可以明确地告诉浏览器哪些源可以访问服务器的资源。要拒绝跨域访问，可以配置CORS响应头以禁止所有来源的访问。

设置Access-Control-Allow-Origin为特定的域名

如果只想允许来自特定域名的请求，可以在服务器响应头中设置Access-Control-Allow-Origin为该域名。例如，Access-Control-Allow-Origin:https://example.com。

设置Access-Control-Allow-Origin为null或空字符串

在某些情况下，将Access-Control-Allow-Origin设置为null或空字符串（""）可以拒绝所有跨域请求。但请注意，这种方法可能不是所有浏览器都支持，且可能引发其他安全问题。

设置Access-Control-Allow-Origin头部

如果服务器响应中没有包含Access-Control-Allow-Origin头部，或者该头部的值不匹配请求中的Origin头部，浏览器将拒绝跨域访问。

2. 防火墙规则

防火墙可以用于控制进出网络的流量，基于源IP、目标IP、端口等进行配置。通过配置防火墙规则，可以拒绝来自特定域名或IP地址的跨域请求。

确定要拒绝的域名或IP地址范围： 首先需要确定哪些域名或IP地址的跨域请求需要被拒绝。
配置防火墙规则： 根据所使用的防火墙软件或硬件设备，配置相应的规则以拒绝来自这些域名或IP地址的跨域请求。

3. 服务器配置

大多数Web服务器（如Apache、Nginx、IIS等）都提供了丰富的配置选项，可以用于控制访问权限。通过修改服务器配置文件，可以拒绝跨域访问。

Apache配置

在.htaccess 文件或主配置文件中添加规则，已拒绝来自特定域名或IP的请求。例如，使用Order allow.deny 和Deny from指令。

Nginx配置

在nginx.conf文件或相关配置文件中添加规则，以拒绝来自特定域名或IP地址的请求。例如，使用location块和deny指令。

IIS配置

在IIS管理器中，通过配置请求筛选器、IP地址和域名限制等功能，拒绝来自特定域名或IP地址的请求。

4. Web应用安全设置

除了上述方法外，还可以在Web应用层面进行安全设置，以拒绝跨域访问。

API接口保护

确保只有授权的客户端可以访问API接口。可以使用身份验证和授权机制（如OAuth、JWT等）来保护API接口。

静态资源保护

防止其他网站盗用你的图片、CSS、JavaScript等资源。可以通过设置适当的HTTP头部（如Cache-Control、Content-Type等）和服务器配置来实现。

输入验证和过滤

对所有用户输入进行验证和过滤，以防止跨站脚本攻击（XSS）和其他安全漏洞。

5. 其他注意事项

定期更新和维护：定期更新服务器软件、防火墙规则和安全设置，以确保系统的安全性和稳定性。
监控和日志记录：监控跨域访问尝试和其他可疑活动，并记录相关日志以便于后续分析和处理。
用户教育和意识提升：提升用户对网络安全的认识和意识，教育他们不要随意点击不明链接或下载未知来源的文件。

通过上述方法，可以有效地拒绝跨域访问，提高系统的安全性和隐私保护水平。

10. 跨源脚本API访问

在 JavaScript 中，iframe.contentWindow、window.parent、window.open 和 window.opener 这些 API 允许文档（或称为“窗口”）之间直接相互引用。然而，当两个文档的源（即它们的协议、域名和端口）不同时，出于安全考虑，浏览器会对这些引用施加一些限制。这主要是为了防止跨站脚本攻击（XSS）和跨站请求伪造（CSRF）等安全威胁。这些限制主要体现在对 Window 和 Location 对象的访问上。下面是对这两个对象在跨源情况下的详细解释：

1. Window 对象

Window 对象代表一个浏览器窗口或框架，并提供了大量的方法和属性来控制窗口的行为和访问其内容。当两个文档跨源时，尝试访问另一个文档的 Window 对象的某些属性和方法会受到限制。具体来说：

属性和方法的访问限制：跨源时，你不能直接访问另一个文档的 Window 对象的很多属性和方法。例如，你不能读取或修改另一个文档的 DOM，也不能调用其 JavaScript 函数。
通信机制：虽然直接访问受限，但浏览器提供了其他机制来实现跨文档通信，比如 window.postMessage 方法。这种方法允许两个不同源的文档安全地发送消息给对方，只要双方都愿意接收这些消息。

2. Location 对象

Location 对象包含有关当前文档的位置（URL）信息，并提供了改变浏览器位置（即导航到新页面）的方法。在跨源情况下，对 Location 对象的访问也受到一定的限制：

读取限制：虽然你可以读取当前文档的 Location 对象来获取 URL 信息，但你不能直接读取另一个跨源文档的 Location 对象。这是为了防止敏感信息（如 URL 中的查询参数）被恶意网站获取。
导航限制：尽管你不能直接读取跨源文档的 Location 对象，但在某些情况下，你可能仍然能够通过某些方式（如通过点击链接或表单提交）导致用户导航到另一个页面。然而，这种导航通常不会暴露给脚本，以防止脚本利用这一点进行恶意操作。

3. 安全考虑

这些限制是浏览器同源策略（Same-Origin Policy）的一部分，它是 Web 安全的基础之一。同源策略确保了一个源（协议、域名和端口）的文档不能对另一个不同源的文档进行不受控制的访问和操作。这有助于保护用户的数据安全和隐私，防止恶意网站进行跨站脚本攻击、数据窃取或其他恶意行为。

4. 总结

在 JavaScript 中，当两个文档的源不同时，对 Window 和 Location 对象的访问会受到严格的限制。这些限制是为了遵守同源策略，保护用户的数据安全和隐私。尽管直接访问受限，但浏览器提供了如 window.postMessage 等机制来实现跨文档的安全通信。

11. 跨源数据存储访问

访问存储在浏览器中的数据，Web Storage（包括 localStorage 和 sessionStorage）以及 IndexedDB 都是基于源的存储机制。这意味着每个源（由协议、域名和端口组成）都拥有自己独立的存储空间，并且遵循同源策略（Same-Origin Policy）。

1. Web Storage

localStorage：用于持久存储数据，即使浏览器关闭，数据也不会丢失。每个源都有自己的 localStorage 空间，不同源之间的数据是隔离的。
sessionStorage：用于存储页面会话期间的数据。当页面会话结束（例如，用户关闭浏览器标签页）时，数据会被清除。同样，每个源都有自己的 sessionStorage 空间。

2. IndexedDB

是一个低级 API，用于在用户的浏览器中存储大量结构化数据，包括文件/二进制数据。与 Web Storage 一样，IndexedDB 也是基于源的，每个源都有自己的数据库实例。

3. 跨源数据共享的方法

由于同源策略的限制，一个源中的脚本无法直接访问另一个源中的 Web Storage 或 IndexedDB 数据。这种隔离是浏览器安全模型的重要组成部分。管存在同源策略的限制，但在某些情况下，开发者可能需要实现跨源数据共享。以下是一些可能的方法：

使用 CORS（跨源资源共享）：对于某些类型的请求（如 AJAX 请求），服务器可以通过设置 CORS 相关的 HTTP 头来允许跨源访问。然而，这通常不适用于 Web Storage 或 IndexedDB。
服务器端的代理：在同源策略允许的范围内设置一个代理服务器，通过代理服务器来转发跨源请求和响应。这种方法需要在服务器端进行配置。
使用 postMessage 方法：对于需要跨文档通信的情况，可以使用 window.postMessage 方法在不同源的文档之间安全地发送消息。虽然这不是直接访问存储数据的方法，但它可以用于实现跨源的数据交换。
OAuth 或其他认证机制：在某些情况下，可以通过使用 OAuth 或其他认证机制来实现跨源的数据共享。这通常涉及到用户授权和访问令牌的使用。
使用 CORS（跨源资源共享）：对于某些类型的请求（如 AJAX 请求），服务器可以通过设置 CORS 相关的 HTTP 头来允许跨源访问。然而，这通常不适用于 Web Storage 或 IndexedDB。
服务器端的代理：在同源策略允许的范围内设置一个代理服务器，通过代理服务器来转发跨源请求和响应。这种方法需要在服务器端进行配置。
使用 postMessage 方法：对于需要跨文档通信的情况，可以使用 window.postMessage 方法在不同源的文档之间安全地发送消息。虽然这不是直接访问存储数据的方法，但它可以用于实现跨源的数据交换。
OAuth 或其他认证机制：在某些情况下，可以通过使用 OAuth 或其他认证机制来实现跨源的数据共享。这通常涉及到用户授权和访问令牌的使用。