本文永久链接 – https://tonybai.com/2024/01/01/go-testing-by-example

2023年11月初，Go语言技术负责人Russ Cox在GopherCon Australia 2023大会上进行了题为“Go Testing By Example”的演讲：

12月初Russ Cox重新录制了该演讲内容的视频，并在个人网站上放了出来。这个演讲视频是关于如何编写好的Go测试的，Russ Cox介绍了20个实用建议，非常值得Go初学者甚至Go资深开发者学习并应用到实践中。这里是基于该视频整理的文字稿(可能并非逐字逐句)，供广大Gopher参考。

注：在GopherCon Australia 2023，退休后暂定居澳大利亚的Go语言之父Rob Pike也做了一个名为“What We Got Right, What We Got Wrong”的主题演讲。在Go开源14年之后，有很多事情值得思考。这个演讲“事后诸葛亮般地”探讨了Go迄今为止取得的一些经验教训：不仅包括进展顺利的方面，还包括本可以做得更好的方面。可惜目前该演讲视频或文字稿并未放出，我们也只能等待。

大家好！这是几周前我在GopherCon Australia 2023进行的一次演讲，演讲的内容是关于如何编写好的测试。

不过首先让我们来思考一下为什么我们要编写测试。一些有关编程的书中常讲到：测试是为了发现程序中的错误！比如Brian W. Kernighan和Rob Pike合著的《The Practice of Programming》一书中讲到：“测试是一种坚定的、系统地尝试，旨在破坏你认为可以正确运行的程序”。这是真实的。这就是为什么程序员应该编写测试。但对于今天在这里的大多数人来说，这不是我们编写测试的原因，因为我们不仅仅是程序员，我们是软件工程师。什么意思呢？我想说的是，软件工程就是当你编程时增加时间和其他程序员时所发生的事情。编程意味着让程序运行，你有一个问题需要解决，你编写一些代码，运行它，测试它，调试它，得到答案，你就完成了。这本已经相当困难了，而测试是该过程的重要组成部分。但软件工程意味着你在长期与其他人一起开发的程序中完成所有这些工作，这改变了测试的性质。

让我们先看一个对二分查找函数的测试：

如图所示，这个函数接受一个有序(sorted)切片、一个目标值(target)和一个比较函数(cmp)。它使用二分搜索算法查找并返回两个内容：第一，如果目标存在，则返回其索引(index)，第二是一个布尔值，指示目标是否存在。

大多数二分查找算法的实现都有错误，这个也不例外。我们来测试一下。

下面是一个很好的二分搜索的交互式测试：

你输入两个数字n和t，测试程序便创建一个包含n个元素的切片，其元素值按10倍增，然后程序在切片中搜索t并打印结果，然后你反复重复这一过程。

这可能看起来不足为奇，但有多少人曾经通过运行这种交互式测试程序来测试生产环境用的代码(production code)？我们所有人都这样做过。当你独自编程时，像这样的交互式测试程序对于查找bug非常有用，到目前为止代码看起来可以正常工作。

但这个交互式测试程序只适合独自编程时使用，如果你从事软件工程，意味着你要长时间保持程序的运行，并与其他人合作，那么这种类型的测试程序就不太有用了。

你需要一种每个人都可以在日常工作中运行的测试程序，可以在他们编写代码的同时运行，并且可以由计算机在每次代码提交时自动运行。问题在于仅通过手动测试程序只能确保它在今天正常工作，而自动化、持续的测试可以确保它在明天和未来都可以正常工作，即使其他不熟悉这段代码的人开始对其进行维护。并且我们要明确一点：那个不太熟悉代码的人可能是指未来六个月甚至六周后的你。

这是一个软件工程师的测试。你可以在不了解代码工作原理的情况下运行它。任何同事或任何计算机都可以使用”go test”运行该测试，并可以立即知道该测试是否通过。我肯定你已经见过这样的测试了。

软件工程的理想是拥有能够捕捉到后续可能出现的所有错误的测试。如果你的测试达到了这个理想状态，那么当你的所有测试都通过时，你应该可以放心地自动将你的代码部署到生产环境中，这就是人们所称的持续部署。如果你还没有这样做，如果这个想法让你感到紧张，那么你应该问问自己为什么。要么你的测试已经足够好，要么它们还不够好。如果它们足够好，那为什么不这样做呢？而如果它们不够好，那就倾听这些疑虑，并找出它们告诉你哪些测试被遗漏了。

几年前，我正在为新的Go官方网站go.dev编写代码。那时我们还在手动部署该网站，并且至少每周一次。我做的一项代码变更在我的机器上运行正常，但在部署到生产环境后便无法正常工作了，这着实令人非常烦恼和尴尬。解决办法是进行更好的测试和自动化的持续部署。现在，每当代码库中有新的提交时，我们使用一个Cloud Build程序来运行本地测试，并将代码推送到一个全新的服务器，然后运行一些只能在生产环境中运行的测试。如果一切正常，我们会将流量打到新的服务器。这样做改善了两点。首先，我不再导致令人尴尬的网站宕机。其次，每个人都不再需要考虑如何部署网站。如果他们想做变更，比如修复拼写错误或添加新的博客文章，他们只需发送更改请求，对其进行审核、测试和提交，然后自动化流程会完成其余工作。

要确信当其他人更改代码时你的程序不会出错，要确信只要测试通过就可以随时将程序推送到生产环境，你需要一套非常好的测试。但是什么样的测试才算是好的呢？

一般来说，使测试代码优秀的因素与使非测试代码优秀的因素是相同的：勤奋(hard work)、专注(attention)和时间(time)。对于编写优秀的测试代码，我没有什么“银弹式”的或硬性的规则，就像编写优秀的非测试代码一样。然而，我确实有一系列基于我们在Go上的良好实践的建议，我将在这次演讲中分享20个编写优秀测试代码的实用建议。

建议1：让添加新测试用例变得容易

这是最重要的建议。因为如果添加一个新测试用例很困难，你就不会去做。在这方面，Go已经提供了很好的支持。

上图是函数Foo的一个最简单的测试。我们专门设计了Go测试，使其非常容易编写。没有繁杂的记录或仪式会妨碍你。在包级别的测试中，这已经相当不错了，但在特定的包中，你可以做得更好。

我相信你已经了解了表驱动测试。我们鼓励使用表驱动测试，因为它们非常容易添加新的测试用例。这是我们之前看到的那个测试用例：假设我们只有这一个测试用例，然后我们想到了一个新的测试用例。我们根本不需要编写任何新的代码，只需要添加一行新的数据。如果目标是“使添加新的测试用例变得容易”，那么对于像这样的简单函数，向表中添加一行数据就足够了。不过，这也引出了一个问题：我们应该添加哪些测试用例？这将引导我们来到下一个建议。

建议2：使用测试覆盖率来发现未经测试的代码

毕竟，测试无法捕捉到未运行的代码中的错误。Go内置了对测试覆盖率的支持。下面是它的样子：

你可以运行“go test -coverprofile”来生成一个覆盖率文件，然后使用“go tool cover”在浏览器中查看它。在上图的显示中，我们可以看到我们的测试用例还不够好：实际的二分查找代码是红色的，表示完全未经测试。下一步是查看未经测试的代码，并思考什么样的测试用例会使这些代码行运行。

经过仔细检查，我们只测试了一个空切片，所以让我们添加一个非空的切片的测试用例。现在我们可以再次运行覆盖率测试。这次我将用我写的一个小命令行程序“uncover”来读取覆盖率文件。Uncover会显示未被测试覆盖的代码行。它不会给你网页视图那样的全局视图，但它可以让你保持在一个终端窗口中。Uncover向我们展示了只剩下一行代码未被测试执行。这是进入切片的第二半部分的行，这是有道理的，因为我们的目标是第一个元素。让我们再添加一个测试，搜索最后一个元素。

当我们运行测试时，它通过了，我们达到了100%的覆盖率。很棒。我们完成了吗？没有，这将引导我们到下一个实用建议。

建议3：覆盖率不能替代思考

覆盖率对于指出你可能忽略的代码部分非常有用，但机械工具无法替代对于高难度的输入、代码中的微妙之处以及可能导致代码出错的情况进行的实际思考。即使代码拥有100%的测试覆盖率，仍然可能存在bug，而这段代码就存在bug。这个提示也适用于覆盖率驱动的模糊测试(fuzzing test)。模糊测试只是尝试通过代码探索越来越多的路径，以增加覆盖率。模糊测试也非常有帮助，但模糊测试也不能替代思考。那么这里缺少了什么呢？

需要注意的一点是，唯一一个无法找到目标的测试用例是一个空输入切片。我们应该检查在具值的切片中无法找到目标的情况。具体来说，我们应该检查当目标小于所有值、大于所有值和位于值的中间时会发生什么。所以让我们添加三个额外的测试用例。

注意添加新测试用例是多么容易。如果你想到一个你的代码可能无法正确处理的情况，添加该测试用例应该尽可能简单，否则你就会觉得麻烦而不去添加。如果太困难，你就不会添加。你还可以看到我们正在开始列举这个函数可能出错的所有重要路径。这些测试对未来的开发进行了约束，以确保二分查找至少能够正常工作。当我们运行这些测试时，它们失败了。返回的索引i是正确的，但表示target是否找到的布尔值是错误的。所以让我们来看看这个问题。

阅读代码，我们发现返回语句中的布尔表达式是错误的。它只检查索引是否在范围内。它还需要检查该索引处的值是否等于target值。所以我们可以进行这个更改，如图所示，然后测试通过了。现在我们对这个测试感到非常满意：覆盖率是良好的，我们也经过了深思熟虑。还能做什么呢？

建议4：编写全面的测试

如果你能够测试函数的每一个可能输入，那就应该这样做。但现实中可能无法做到，但通常你可以在一定约束条件下测试特定数量以内的所有输入。下面是一个二分查找的全面测试：

我们首先创建一个包含10个元素的切片，具体来说就是从1到19的奇数。然后我们考虑该切片的所有可能长度的前缀。对于每个前缀，我们考虑从0到两倍长度的所有可能目标，其中0是小于切片中的所有值，两倍长度是大于切片中的所有值。这将详尽地测试每个可能的搜索路径，以及长度不超过我们的限制10的所有可能尺寸的切片。但是现在我们怎么知道答案是什么呢？我们可以根据测试用例的具体情况进行一些数学计算，但有一种更好、更通用的方法。这种方法是编写一个与真正实现不同的参考实现。理想情况下，参考实现应该明显是正确的，但它只需与真实实现采用不同的方法即可。通常，参考实现将是一种更简单、更慢的方法，因为如果它更简单和更快，你会将其用作真正的实现。在这种情况下，我们的参考实现称为slowFind。测试检查slowFind和Find是否可以在答案上达成一致。由于输入很小，slowFind可以采用一个简单的线性搜索。

通过生成所有可能的输入并将结果与简单的参考实现进行比较，这种模式非常强大。它做的一件重要的事情是覆盖了所有基本情况，例如0个元素的切片、1个元素的切片、长度为奇数的切片、长度为偶数的切片、长度为2的幂的切片等等。大多数程序中的绝大多数错误都可以通过小规模的输入进行重现，因此测试所有小规模的输入非常有效。事实证明，这个全面测试通过了。我们的思考相当不错。

现在，如果全面测试失败，那意味着Find和slowFind不一致，至少有一个有bug，但我们不知道是哪一个有问题。添加一个直接测试slowFind会有所帮助，而且很容易，因为我们已经有了一个测试数据表。这是表驱动测试的另一个好处：可以使用这些表来测试多个实现。

建议5：将测试用例与测试逻辑分开

在表驱动测试中，测试用例在表中，而处理这些测试用例的循环则是测试逻辑。正如我们刚才所看到的，将它们分开可以让你在多个上下文中使用相同的测试用例。那么现在我们的二分查找函数完成了吗？事实证明没有，还有一个bug存在，这引导我们到下一个问题。

建议6：寻找特殊情况

即使我们对所有小规模情况进行了全面测试，仍然可能存在潜在的bug：

现在，这里再次展示了代码。还剩下一个bug。你可以暂停视频，花一些时间来查看它。

有人看出bug在哪里了吗？如果你没有看到，没关系。这是一个非常特殊的情况，人们花了几十年的时间才注意到它。Knuth告诉我们，尽管二分查找在1946年发表，但第一个正确的二分查找实现直到1964年才发表。但是这个bug直到2006年才被发现。

bug是这样的，如果切片中的元素数量非常接近int的最大值，那么i+j会溢出，因此i+j/2就不是切片中间位置的正确计算方法了。这个bug于2006年在一个使用64位内存和32位整数的C程序中被发现，这个程序用于索引包含超过10亿个元素的数组。在Go语言中，这种特定组合基本上不会发生，因为我们要求使用64位内存时，也要使用64位整数，这正是为了避免这种bug。但是，由于我们了解到这个bug，而且你永远不知道你或其他人将来如何修改代码，所以避免这个bug是值得的。

有两种常见的修复方法可以避免数学计算溢出。速度稍快的方法是进行无符号除法。假设我们修复了这个问题。现在我们完成了吗？不。因为我们还没有编写测试。

建议7：如果你没有添加测试，那就没有修复bug

这句话在两个不同的方面下都是正确的。

第一个是编程方面。如果你没有进行测试，bug可能根本没有被修复。这听起来可能很愚蠢，但你有多少次遇到过这种情况？有人告诉你有一个bug，你立即知道修复方法。你进行了更改，并告诉他们问题已经修复。然后他们却回来告诉你，不，问题还存在。编写测试可以避免这种尴尬。你可以说，很抱歉我没有修复你的bug，但我确实修复了一个bug，并会再次查看这个问题。

第二个是软件工程方面，即“时间和其他程序员”的方面。bug并不是随机出现的。在任何给定的程序中，某些错误比其他错误更有可能发生。因此，如果你犯了一次这个错误，你或其他人很可能在将来再次犯同样的错误。如果没有测试来阻止它们，bug就会重新出现。

现在，这个特定的测试很难编写，因为输入范围非常大，但即使测试很难编写，这个建议仍然成立。实际上，在这种情况下，这个建议通常更为正确。

为了测试这种情况，一种可能性是编写一个仅在32位系统上运行的测试，对两千兆字节的uint8进行二分查找。但这需要大量的内存，并且我们现在已经没有多少32位系统了。对于测试这种难以找到的bug，通常还有更巧妙的解决方案。我们可以创建一个空结构体的切片，无论它有多长，都不会占用内存。这个测试在一个包含MaxInt个空结构体的切片上调用Find函数，寻找一个空结构体作为目标，但是它传入了一个总是返回-1的比较函数，声称切片元素小于目标。这将使二分查找探索越来越大的切片索引，从而导致溢出问题。如果我们撤销我们的修复并运行这个测试，那么测试肯定会失败。

而使用了我们的修复后，测试通过了。现在bug已经修复了。

建议8：并非所有东西都适合放在表中

这个特殊情况不适合放在表中，但这没关系。但是很多东西确实适合放在表中。

这是我最喜欢的一个测试表之一。它来自fmt.Printf的测试用例。每一行都是一个printf格式、一个值和预期的字符串。真实的表太大了，无法放在幻灯片上，但这里摘录了一些表中的代码行。

如果你仔细阅读整个表，你会看到其中一些明显是修复bug的内容。记住建议7：如果你没有添加测试，那就没有修复bug。表格使得添加这些测试变得非常简单，并且添加这些测试可以确保这些bug不会再次出现。

表格是将测试用例与测试逻辑分离并且方便添加新的测试用例的一种方法，但有时你会有很多测试，甚至写Go语法的开销也是不必要的。例如，这里是strconv包的一个测试文件，用于测试字符串与浮点数之间的转换。你可能认为编写解析器来处理这个输入太麻烦了，但一旦你知道了如何处理，其实并不需要太多工作，而且定义测试专用的小型语言实际上非常有用。

因此，我将快速介绍一下解析器，以展示它并不复杂。我们读取文件，然后将其分割成行。对于每一行，我们计算错误消息的行号。切片元素0表示第1行。我们去掉行尾的任何注释。如果行为空白行，我们跳过它。到目前为止，这是相当标准的样板代码。现在是重点。我们将行分割为字段，并提取出四个字段。

然后根据类型字段在float32或float64的数学运算中进行转换。myatof64基本上是strconv.ParseFloat64的变体，不同之处在于它处理允许我们按照从论文中复制的方式编写测试用例的十进制p格式。

最后，如果结果不是我们想要的，我们打印错误。这非常类似于基于表格的测试。我们只是解析文件，而不是遍历表格。它无法放在一个幻灯片上，但在开发时它可以放在一个屏幕上。

建议9：测试用例可以放在testdata文件中

测试不必都要放在源代码中。

作为另一个例子，Go正则表达式包包含了一些从AT&T POSIX正则表达式库复制过来的testdata文件。我不会在这里详细介绍，但我很感激他们选择为该库使用基于文件的测试，因为这意味着我可以重用testdata文件，将其用于Go。这是另一种ad-hoc格式，但它易于解析和编辑。

建议10：与其他实现进行比较

与AT&T正则表达式的测试用例进行比较有助于确保Go的包以完全相同的方式处理各种边缘情况。我们还将Go的包与C++的RE2库进行比较。为了避免需要编译C++代码，我们以记录所有测试用例的方式运行它，并将该文件作为testdata提交到Go中。

在文件中存储测试用例的另一种方法是使用成对的文件，一个用于输入，一个用于输出。为了实现go test -json，有一个名为test2json的程序，它读取测试输出并将其转换为JSON输出。测试数据是成对的文件：测试输出和JSON输出。

这是最简短的文件。测试输出位于顶部，它是test2json的输入，应该生成底部的JSON输出。以下是实现，展示了从文件中读取测试数据的惯用方法。

我们首先使用filepath.Glob查找所有的testdata。如果失败或找不到任何文件，我们会报错。否则，我们循环遍历所有文件。对于每个文件，我们通过获取基本文件名（不包括testdata/目录名和文件后缀）来创建子测试名称。然后我们用该名称运行一个子测试。如果你的测试用例足够复杂，每个文件一个子测试通常是有意义的。这样，当一个测试用例失败时，你可以使用go test -run只运行特定的文件。

对于实际的测试用例，我们只需要读取文件，运行转换器，并检查结果是否匹配。对于检查，我最开始使用了bytes.Equal，但随着时间的推移，编写一个自定义的diffJSON函数来解析两个JSON结果并打印实际差异的详细说明变得更有价值。

建议11：使测试失败易读

回顾一下，我们已经在二分查找中看到了这一点。

我认为我们都同意粉色框不是一个好的失败。但是黄色框中有两个细节使得这些失败尤为出色。首先，我们在单个if语句中检查了两个返回值，然后在简洁的单行中打印了完整的输入和输出。其次，我们不会在第一个失败处停止。我们使用t.Error而不是t.Fatal，以便执行更多的测试用例。结合起来，这两个选择让我们可以看到每个失败的完整细节，并在多个失败中寻找模式。

回到test2json，这是它的测试失败的情况。它计算出哪些事件是不同的，并清晰地标记它们。重要的是，在你编写测试时，你不必写这种复杂的代码。bytes.Equal在开始时是可以的，并且可以专注于代码。但是随着失败变得更加微妙，并且你发现自己花费太多时间只是阅读失败输出，这是一个好的信号，它告诉你是时候花一些时间使其更易读了。此外，如果确切的输出发生更改并且你需要更正所有的测试数据文件，这种类型的测试可能会有点麻烦。

建议12：如果答案可能会改变，编写代码来更新它们

通常的做法是在测试中添加一个“-update”标志。这是test2json的更新代码示例。

测试定义了一个新的“-update标志”。当标志为true时，测试将计算的答案写入答案文件，而不是调用diffJSON。现在，当我们对JSON格式进行有意的更改时，“go test -update”会更新所有答案。你还可以使用版本控制工具如“git diff”来审查更改，并在看起来不正确时撤销更改。在谈论测试文件的主题上，有时将一个测试用例分割成多个文件会很烦人。如果我今天编写这个测试，我就不会这样做。

建议13： 使用txtar进行多文件测试用例

注：导入txtar：import “golang.org/x/tools/txtar”

Txtar是我们几年前专门为解决多文件测试用例问题而设计的一种新的存档格式。其Go解析器位于golang.org/x/tools/txtar中，我还找到了用Ruby、Rust和Swift编写的解析器。

Txtar的设计有三个目标。首先，足够简单，可以手动创建、编辑和阅读。其次，能够存储文本文件的树形结构，因为我们在go命令中需要这个功能。第三，能够在git历史记录和代码审查中进行良好的差异比较。其他的包括成为完全通用的存档格式、存储二进制数据、存储文件模式(file mode)、存储符号链接等都不是目标，因为存档文件(archived file)格式往往变得十分复杂，而复杂性与第一个目标直接相矛盾。这些目标和非目标导致了一个非常简单的格式。下面是一个示例：txtar文件以注释开头。

本例中为”Here are some greetings.”，然后通常会有零个或多个文件，每个文件由形如”– 文件名 –”的行引入。这个存档包含两个单行文件，hello和g’day。就是这样，这就是整个格式。没有转义，没有引用，没有对二进制数据的支持，没有符号链接，没有可能的语法错误，没有复杂之处。下面是一个在测试数据中使用txtar文件的真实示例。

该测试数据用于计算差异的包：在这种情况下，注释对于人们来说很有用，用于记录正在进行的测试，然后在这个测试中，每个用例由两个文件和它们的差异后面跟随的两个文件组成。

使用txtar文件几乎和编写它们一样简单。下面是我们之前查看的diff包的测试。

这是通常的基于文件的循环，但我们在文件上调用了txtar.ParseFile。然后我们坚持认为存档包含三个文件，第三个文件的名称为diff。然后我们对两个输入文件进行差异比较，并检查结果是否与预期的差异匹配。

这就是整个测试。你可能已经注意到，在使用之前，文件数据会被传递给”clean”函数进行清理。clean函数允许我们在不使txtar格式本身复杂化的情况下添加一些特定于diff的扩展。

第一个扩展处理以空格结尾的行，在差异中确实会出现这种情况。许多编辑器希望去除这些尾随空格，因此测试允许在txtar的数据行末尾放置$，并且clean函数会删除该$。在这个示例中，标记的行需要以一个空格结尾。

此外，txtar要求文件中的每一行都以换行符结尾，但我们希望测试diff在不以换行符结尾的文件上的行为。因此，测试允许在结尾处放置一个字面意义上的“尖号D”。clean函数会删除“尖号D”和其后的换行符。在这种情况下，’new’文件最终没有最后的换行符，而diff正确报告了这一点。因此，尽管txtar非常简单，你也可以轻松地在其上添加自己的格式调整。当然，重要的是要记录这些调整，以便下一个参与测试的人能够理解它们。

建议14：对现有格式进行注解(annotation)来创建测试迷你语言

对现有格式进行注释，比如在txtar中添加$和尖号D，是一个强大的工具。

这里是对现有格式进行注释的一个示例。这是Go类型检查器(type checker)的一个测试。这是一个普通的Go输入文件，但是期望的类型错误已经以/*ERROR*/注释的形式添加了进去。我们使用/*注释，这样我们就可以将它们放置在错误报告的确切位置上。测试运行类型检查器，并检查它是否在预期位置产生了预期的消息，并且没有产生任何意外的消息。下面是类型检查器的另一个示例。

在这个测试中，我们在通常的Go语法之上添加了一个assert注释。这使我们能够编写常量算术的测试，就像这个例子一样。类型检查器已经计算了每个常量表达式的布尔值，所以检查assert其实只是检查常量是否被求值为true。下面是另一个带有注释的格式示例。

Ivy是一个交互式计算器。你输入程序，通常是简单的表达式，它会打印出答案。测试用例是看起来像这样的文件：未缩进的行是Ivy的输入，缩进的行是注释，指示Ivy应该打印出预期的输出。编写新的测试用例再也没有比这更简单的了。这些带注释的格式扩展了现有的解析器和打印器(printer)。有时编写自己的解析器和打印器是有帮助的。毕竟，大多数测试涉及创建或检查数据，当你可以使用方便的形式处理数据时，这些测试总是可以更好。

建议15：编写解析器和打印器来简化测试

这些解析器和打印器不一定是用于testdata中数据文件的独立脚本。你也可以在常规的Go代码中使用它们。

这是一个运行deps.dev代码的一个测试片段。这个测试设置了一些数据库表行。它调用了一个使用数据库并正在进行测试的函数。然后它检查数据库是否包含了预期的结果。Insert和Want调用使用了一个专门为这些测试编写的用于数据库内容的迷你语言。解析器就像它看起来的那样简单：它将输入分割成行，然后将每行分割成字段。第一行给出了列名。就是这样。这些字符串中的确切间距并不重要，但是如果它们都对齐，当然看起来更美观。

因此，为了支持这个测试，deps.dev团队还有一个专门为这些测试编写的代码格式化程序。它使用Go标准库解析测试源代码文件。然后它遍历Go语法树，查找Insert或Want的调用。它提取字符串参数并将它们解析为表格。然后它将表格重新打印为字符串，将字符串重新插入语法树中，并重新打印语法树为Go源代码。这只是gofmt的一个扩展版本，使用了与gofmt相同的包。我这里不会展示这些代码，但代码量其实不多。

解析器和打印器需要花费了一些时间来编写。但现在，每当有人编写一个测试时，编写测试就更容易了。每当一个测试失败或需要更新时，调试也更容易了。如果你正在进行软件工程，收益将随着程序员数量和项目生命周期的增加而扩大。对于deps.dev来说，已经花费在这个解析器和打印器上的时间已经多次节省了。或许更重要的是，因为测试更容易编写，你可能会写更多的测试，这将导致更高质量的代码。

建议16：代码质量受测试质量限制

如果你不能编写高质量的测试，你将无法编写足够的测试，并且最终无法得到高质量的代码。

现在我想向你展示一些我曾经参与的最高质量的测试，这些测试是针对go命令的测试。它们将我们到目前为止看到的许多思想汇集在一起。这是一个简单但真实的go命令测试。这是一个txtar输入，其中包含一个名为hello.go的文件。archive comment是一个逐行简单命令语言编写的脚本。在脚本中，”env”设置一个环境变量来关闭Go module机制。井号引入注释。而”go”运行go命令，它应该运行hello world。该程序应该将hello world打印到标准错误中。”stderr”命令检查前一个命令打印的标准错误流是否与正则表达式匹配。因此，这个测试运行”go run hello.go”并检查它是否将hello world打印到标准错误中。

这里是另一个真实的测试。请注意底部的a.go是一个无效的程序，因为它导入了一个空字符串。第一行开头的感叹号是一个”非”操作符。NOT go list a.go意味着go list a.go应该失败。下一行的”NOT stdout .”表示标准输出不应该有与正则表达式”.”匹配的内容，也就是不应该打印任何文本。接下来，标准错误流应该有一个无效的导入路径的消息。最后，不应该发生panic。

建议17：使用脚本可以编写很好的测试

这些脚本使添加新的测试用例变得非常容易。

这是我们最小的测试用例：两行代码。最近我在破坏了unknown command的错误消息后添加了这个测试用例。总共，我们有超过700个这样的脚本测试，从两行到500多行不等。

这些测试脚本取代了一个更传统的使用方法(method)的测试框架。这张幻灯片展示了其中一个真实的测试，前面是脚本编写的测试用例，后面是等价的Go编写的传统测试代码。细节并不重要，只需注意脚本要比传统测试方法更容易编写和理解。

建议18：尝试使用rsc.io/script来创建基于脚本的测试用例

距离我们创建go脚本测试已经过去了大约五年时间，我们对这个特定的脚本引擎非常满意。Bryan Mills花了很多时间为它提供了一个非常好的API，早在11月份，我将其发布到了rsc.io/script以供导入使用。现在我说”尝试”是因为它还比较新，并且具有讽刺意味的是，它本身的测试还不够多，因为可导入的包只有几周的历史，但你仍然可能会发现它很有用。当我们对其有更多经验时，我们可能会将其放在更官方的位置上。如果你尝试了它，请告诉我结果如何。

提取脚本引擎的动机是为了在go命令测试的不同部分中重用它。这个脚本正在准备一个包含我们想要在常规go命令脚本测试中导入的模块的Git存储库(repo)。你可以看到它设置了一些环境变量，运行了真正的git init，设置了时间，在存储库中运行了更多的git命令来添加一个hello world文件，然后检查我们得到了我们想要的存储库。再一次，测试并不是从一开始就是这样的，这引出了下一个实用建议。

建议19：随着时间的推移改进你的测试

最初，我们没有这些存储库脚本。我们手工创建小型测试存储库，并将它们发布到GitHub、Bitbucket和其他托管服务器，具体取决于我们所需的版本控制系统。这种方法还算可以，但这意味着如果这些服务器中的任何一个宕机，测试就会失败。最终，我们花时间构建了自己的云服务器，可以为每个版本控制系统提供存储库服务。现在，我们手工创建存储库，将其压缩并复制到服务器上。这样做更好，因为现在只有一个服务器可能会使我们的测试失败，但有时也会出现网络问题。测试存储库本身也没有进行版本控制，并且与使用它们的测试不在一起，这也是一个问题。作为测试的一部分，基于脚本的版本完全可以在本地构建和提供这些存储库。而且现在很容易找到、更改和审查存储库的描述。这需要很多基础设施，但也测试了很多代码。如果你只有10行代码，你完全不需要拥有数千行的测试框架。但是如果你有十万行代码，这大约是go命令的规模，那么开发几千行代码来改进测试，甚至是一万行代码，几乎可以肯定是一个不错的投资。

建议20：追求持续部署

也许出于策略原因，你无法每次都实际部署那些通过了所有测试的代码提交，但无论如何都要追求这一目标。正如我在演讲开始时提到的，对于持续部署的任何疑问都是有益的小声音，它们告诉你需要更好的测试。而更好的测试的关键当然是让添加新测试变得容易。即使你从未实际启用持续部署，追求这一目标也可以帮助你保持诚实，提高测试的质量和代码的质量。

我之前提到过Go官方网站使用了持续部署。在每次提交时，我们运行测试来决定是否可以部署最新版本的代码并将流量路由到它。此时，你不会感到惊讶，我们为这些测试编写了一个测试脚本语言。上图是它们的样子。每个测试以一个HTTP请求开始。这里我们GET主页go.dev。然后对响应进行断言。每个断言的形式为”字段(field)，运算符(operator)，值(value)”。这里字段(field)是body，运算符(operator是contains，值(value)是body中必须包含的字面值。这个测试检查页面是否渲染过了，因此它检查基本文本以及一个副标题。为了更容易编写测试，根本没有引号。值就是运算符后面的其余部分。接下来是另一个测试用例。出于历史原因，/about需要重定向到pkg.go.dev。

这是另一个案例。这里没有什么特别的，只是检查案例研究页面是否渲染(rendering)了，因为它是由许多其他文件合成的。测试可以检查的另一个字段是HTTP响应代码，这是一个错误修复。我们错误地在Go存储库根目录中提供了这些文件，就好像它们是Go网站页面一样。我们希望改为返回404。你还可以测试标头foo的值，其中foo是某个标头。在这种情况下，标头Content-Type需要正确设置为主博客页面及其JSON feed。

这是另一个示例。这个示例使用正则表达式匹配运算符tilde和“\s+”语法，以确保页面具有正确的文本，无论单词之间有多少空格。这变得有点老套了，所以我们添加了一个名为trimbody的新字段，它是将所有空格序列替换为单个空格后的body。这个示例还显示了值可以作为多个缩进的行提供，以便更容易进行多行匹配。

我们还有一些无法在本地运行但在生产环境中仍值得运行的测试，因为我们将实时流量迁移到服务器之前需要进行这些测试。下面是其中两个。这些依赖于对生产环境playground后端的网络访问。这些案例除了URL不同之外都是相同的。这不是一个非常易读的测试，因为这些是我们唯一的POST测试。如果我们添加了更多这样的测试，我可能会花时间使它们看起来更好，以随着时间推移改进你的测试。但是现在它们还可以，它们起到了重要的作用。

最后，和往常一样，添加错误修复很容易。在问题51989中，live web站点根本没有呈现。因此，这个测试检查页面确实呈现并包含一个独特的文本片段。问题51989不会再次发生，至少不会在实际的网站上。肯定会有其他错误，但那个问题已经彻底解决了，这就是进步。以上这些是我有时间向你展示的这些例子。

小结

最后一个想法。我相信你经历过追踪错误并最终发现一个重要的代码片段是错误的情况。但不知何故，这个代码片段的错误大部分时间都无关紧要，或者错误被其他错误的代码抵消了。你可能会想：“这段代码以前是怎么工作的？”如果是你自己编写的代码，你可能会认为自己很幸运。如果是别人编写的代码，你可能会对他们的能力产生质疑，然后又认为他们很幸运。但是，大多数时候，答案并不是运气。对于这段代码为什么会工作的问题的答案几乎总是：因为它有一个测试。当然，代码是错误的，但测试检查了它足够正确，使系统的其他部分可以正常工作，这才是最重要的。也许编写这段代码的人确实是一个糟糕的程序员，但他们是一个优秀的软件工程师，因为他们编写了一个测试，这就是为什么包含该代码的整个系统能够工作的原因。

我希望你从这次演讲中得出的结论不是任何特定测试的具体细节，尽管我希望你可以留意对小型解析器和打印机的良好使用带来的好处。任何人都可以学会编写它们，并且有效地使用它们可以成为软件工程的超能力。最终，这对这些软件包来说是好测试。对于你的软件包，好测试可能看起来会有所不同。这没关系。但要使添加新的测试用例变得容易，并确保你拥有良好、清晰、高质量的测试。请记住，代码质量受测试质量的限制，因此逐步投入改进测试。你在项目上工作的时间越长，你的测试就应该变得越好。并且要追求持续部署，至少作为一种思想实验，以了解哪些方面的测试还不够充分。

总的来说，要像编写优秀的非测试代码一样，思考并投入同样的思想、关心和努力来编写优秀的测试代码，这绝对是值得的。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2023/11/04/understand-go-web-authz-by-example

在前面的系列文章中，我们了解了Go Web应用身份认证的几种方式，也知道了该如何相对安全地存储用户的密码信息，最大程度减小在系统数据库被攻破时用户密码信息的泄露程度。

一旦用户通过身份验证，他/她就可以以合法的身份进入到系统中，那么问题来了：用户进入系统后是否就可以“为所欲为”了呢？显然不是! 比如我们以普通用户身份登录github，身份验证成功后，我们只能增删改自己账号下的代码仓库数据或读取其他用户的公开仓库(public)数据，我们无法修改和删除其他用户下面的仓库数据，甚至看不到其他用户的私有仓库。Web应用系统(比如github)的这种对用户可以使用什么功能、可以访问和修改哪些数据的管理和控制，就是授权(Authorization)，简称为AuthZ。

在这篇文章中，我们就结合实例一起来了解一下Web应用都有哪些种授权方式。

1. 授权：基于访问控制策略的评估与决策

在Go Web应用身份认证的几种方式一文中，我们简要说明了身份认证(AuthN)与授权(AuthZ)的关系与差异。授权是基于用户身份认证的基础之上的，按时间发生顺序，授权也是发生在身份认证之后的。

授权的目的是限制合法用户在系统中的操作，限制未经允许的访问。这让很多人将授权与访问控制(access control)直接划上了等号。其实授权与访问控制的确是密不可分的，但它们之间也不是可以简单划等号的。下面示意图展示了一个Web应用系统中授权与访问控制的关系：

从广义上看，授权和访问控制都属于对系统资源或信息的保护，它们的目的是限制未经授权的访问。从具体来看，访问控制关注的是如何控制主体访问对象，是一种机制或方法，它通常会定义访问模型以及相关访问策略；而授权则关注主体是否有权访问对象，是在已知用户身份以及访问控制策略下对访问请求的评估和决策过程，并得出主体是否具有访问权限的最终结果。

从上图我们也可以看到：授权是建立在访问控制之上的。访问控制定义了授权评估所需的模型、策略、机制和规则，授权则是在这套规则下，评估一个主体对一个对象的操作是否被允许，两者关系密不可分。在实现上，我们通常会联合使用“访问控制”和“授权”这两个概念，对外部更多用授权一词作为这个过程的统称。

到这里，我们理解了访问控制与授权的关系 – 访问控制提供了授权评估所需的模型和规则体系。针对不同的应用场景，IT界有几种典型的访问控制模型被提出和使用：

• 访问控制列表（Access Control List，ACL）
• 强制访问控制（Mandatory Access Control，MAC）
• 自主访问控制（Discretionary Access Control，DAC）
• 基于属性的访问控制（Attribute-Based Access Control， ABAC)
• 基于角色的访问控制(Role-Based Access Control， RBAC）

这些模型为我们建立访问策略提供了框架和抽象工具。理解不同访问控制模型的思想和适用场景，可以帮助我们更好地制定系统的安全访问策略。在接下来的内容中，我们会简单介绍这几种访问控制模型，包括它们应用场景、优缺点等。这也将帮助大家建立访问控制和授权评估的整体视角，也可以为后续使用Go语言实现授权控制的实例提供理论基础。

2. 访问控制模型

和任何其它IT技术一样，访问控制模型也有着自己的演进历史过程。下面我们沿着模型演进的时间线，逐个认识一下各个模型。

2.1 访问控制列表（Access Control List，ACL)

ACL是最早的访问控制模型，基于ACL的访问控制会直接在被访问对象(也称为客体(O – Object))上设置允许/拒绝访问的主体(S – Subject)列表，最典型的就是Unix/Linux文件系统中文件的访问模型，如下图：

由此可见，这个模型并非专属于Web应用授权。早在上世纪60年代，它就广泛应用在操作系统中文件系统的访问权限管理。在1965年，Multics操作系统第一个实现了基于ACL模型的文件系统访问权限管理。POSIX曾推出ACL标准化草案，但后来放弃。但ACL并未因此受到打击，后来在NFSv4、Windows、Unix等系统中都有实现。之后，ACL被广泛地应用于网络领域，包括路由器、交换机以及防火墙都借助于访问控制列表来有效地控制用户对网络的访问，从而最大程度地保障网络安全。

ACL模型的优点是简单易用，但也存在灵活性差、难于扩展和满足复杂应用场景访问控制要求等不足。

ACL模型在现代Web应用中使用的越来越少，仅用于少数控制对特定资源访问权限的特定场景。例如，在静态文件服务器中，可以通过在文件系统中使用ACL来控制对文件或目录的访问权限。在复杂的现代Web应用领域，一些由ACL发展演化出的更灵活、更具扩展性的模型已经发展起来并走到了前台，比如后续即将要提到的RBAC和ABAC模型。

2.2 强制访问控制（Mandatory Access Control，MAC）

强制访问控制（Mandatory Access Control，MAC）起源于军用的多级安全系统，在MAC模型中，系统层强制执行访问控制策略，用户层无法更改。在操作系统领域，我们熟知的Linux的SELinux和AppArmor，Windows的Mandatory Integrity Control都属于MAC模型的实现。这种模型通常用于需要高度安全的环境，如军事或政府部门。

不过，MAC由于其中心化的强制控制方式，让其灵活性较差，并且实施起来相对复杂，在现代Web应用领域的使用场景有限。我理解这种MAC模型映射到Web应用领域的具体呈现就是“写死”到代码中的访问控制逻辑和授权决策逻辑，这些“系统层”逻辑是所有到达Web应用的请求必经的且无法进行配置和改变的。

一个典型的应用就是对资源根据安全等级进行的强制访问控制：用户只能访问其安全等级低于或等于自身安全等级的资源。下面是一个演示性质的代码例子：

// authz-examples/mac/main.go

// 定义安全等级
type SecurityLevel int

const (
    // 最低安全等级
    LevelLow SecurityLevel = iota
    // 中等安全等级
    LevelMedium
    // 最高安全等级
    LevelHigh
)

// 定义资源
type Resource struct {
    // 资源名称
    Name string
    // 安全等级
    Level SecurityLevel
}

// 定义用户
type User struct {
    // 用户名
    Name string
    // 安全等级
    Level SecurityLevel
}

// 定义访问控制策略
func CheckAccess(user User, resource Resource) bool {
    // 检查用户的安全等级是否高于或等于资源的安全等级
    return user.Level >= resource.Level
}

func main() {
    // 创建资源
    resource := Resource{
        Name:  "敏感数据",
        Level: LevelHigh,
    }

    // 创建用户
    user := User{
        Name:  "管理员",
        Level: LevelHigh,
    }

    // 检查访问权限
    if CheckAccess(user, resource) {
        fmt.Printf("用户[%s]有权访问资源\n", user.Name)
    } else {
        fmt.Printf("用户[%s]没有权限访问资源\n", user.Name)
    }

    // 创建用户
    user = User{
        Name:  "访客",
        Level: LevelLow,
    }

    // 检查访问权限
    if CheckAccess(user, resource) {
        fmt.Printf("用户[%s]有权访问资源\n", user.Name)
    } else {
        fmt.Printf("用户[%s]没有权限访问资源\n", user.Name)
    }
}

在这个例子中，我们定义了三个安全等级：LevelLow、LevelMedium和LevelHigh。资源和用户都被分配了安全等级。CheckAccess函数用于执行强制的访问控制策略：即用户只能访问其安全等级低于或等于自身安全等级的资源。

2.3 自主访问控制（Discretionary Access Control，DAC）

DAC模型基于资源所有者对其资源的访问权限进行授予和控制。在DAC模型中，资源的所有者可以自主决定哪些用户或实体可以访问他们的资源，以及对资源的访问权限级别。资源的所有者可以决定将资源设置为公开访问、私有访问或仅限于特定用户或用户组的访问。通过授权用户或实体访问资源，资源的所有者具有灵活性和自主权来管理他们的资源。

很显然，这样的DAC模型具有较为灵活的优点，允许资源所有者根据自己的需求和偏好授予和撤销访问权限。这使得资源的访问控制可以针对个体用户进行定制，满足不同用户的需求。同时，DAC模型具备分散控制的特征，它将访问控制的决策权下放给资源的所有者，而不是集中在中央管理机构。这样可以减轻管理负担，并且资源的所有者可以更直接地管理和控制自己的资源。

使用自主访问控制（DAC）模型进行访问控制的Web应用的典型例子是文件共享服务，即我们经常说的网盘服务，比如Google Drive、Dropbox或百度网盘等。在这样的应用中，用户可以上传、存储和共享文件。并使用DAC模型，设置文件或文件夹的访问权限，例如私有、只读或读写访问。用户还可以选择将文件或文件夹的访问权限限制为特定的用户或用户组。

另一种使用DAC模型进行访问控制的Web应用示例是社交媒体应用，这类应用允许用户发布和查看帖子，并给每个帖子分配权限以控制其他用户对其的访问权限，权限可以是“公开”、“好友”、“私人”等，

下面是一个DAC模型的演示性质的代码例子：

// authz-examples/dac/main.go

type Resource struct {
    Name      string
    Owner     string
    AccessMap map[string]bool
}

func (r *Resource) GrantAccess(user string) {
    r.AccessMap[user] = true
}

func (r *Resource) RevokeAccess(user string) {
    r.AccessMap[user] = false
}

func (r *Resource) CanAccess(user string) bool {
    access, exists := r.AccessMap[user]
    if !exists {
        return false
    }
    return access
}

func main() {
    // 创建一个资源
    resource := Resource{
        Name:      "example.txt",
        Owner:     "alice",
        AccessMap: make(map[string]bool),
    }

    // 授予访问权限给用户
    resource.GrantAccess("alice")
    resource.GrantAccess("bob")

    // 验证访问权限
    fmt.Println("alice can access:", resource.CanAccess("alice")) // 输出: true
    fmt.Println("bob can access:", resource.CanAccess("bob"))     // 输出: true
    fmt.Println("eve can access:", resource.CanAccess("eve"))     // 输出: false

    // 撤销访问权限
    resource.RevokeAccess("bob")

    // 验证访问权限
    fmt.Println("bob can access:", resource.CanAccess("bob")) // 输出: false
}

在这个示例中，我们定义了一个Resource结构，包含资源的名称、所有者和访问权限的map。用户可以调用GrantAccess方法授予其他用户对资源的访问权限，RevokeAccess方法则用于撤销用户的访问权限，CanAccess方法用于验证用户是否具有访问资源的权限。通过这个示例，我们也可以看到，MAC模型可以基于一个ACL(比如AccessMap)来实现。

DAC模型那些固有的特点带来的也并不都是好处，也可能给应用带来一定的安全性挑战。比如：由于访问权限由资源的所有者授予，因此可能存在资源所有者授予不当权限的情况。如果资源所有者错误地授予了高权限给不信任的用户或实体，可能会导致安全漏洞。

此外，由于每个资源的所有者可以独立决定访问权限，因此可能会导致系统中存在许多不一致的访问控制策略。这可能增加了管理和维护的复杂性，并且可能导致访问控制规则的碰撞或冲突。

2.4 基于角色的访问控制(Role-Based Access Control，RBAC）

按访问控制模型的出现时间看，ACL是一个60后，MAC是一个70后，DAC是一个80后。那90后的代表是哪个模型呢？没错，就是RBAC。

RBAC是访问控制模型中的一种相对较新的模型，它基于角色和权限的概念来管理对资源的访问。在RBAC模型中，访问权限是根据用户的角色进行授权和控制的。

RBAC模型的核心概念包括：

• 角色（Role）

角色代表一组具有相似职责或权限需求的用户，每个角色可以被分配不同的权限，或者说权限是以角色为最小单位分配的。

• 权限（Permission）

权限代表对资源执行特定操作的授权。权限定义了以特定角色进入系统的用户在系统中可以对某些类资源执行的操作，例如读取、写入、删除等。

• 用户（User）

用户是系统中的实体，通过分配角色来获得相应的权限。

下图是一个RBAC模型中用户、角色、权限与资源之间的直观的关系示意图(使用mermaid绘制)：

这个图比较好理解！首先看权限，权限是一个规则，即允许哪个/哪些角色操作哪个/那些资源。以权限P1为例，它允许角色X操作资源R1和资源R2；权限P2则是允许角色Y和角色Z操作资源R2；权限P3则是允许角色Z操作资源R3。用户则会被赋予角色，并继承角色具有的所有权限。

通过上面图示和说明，我们看到：RBAC模型通过将权限分配给角色，而不是直接分配给用户，简化了权限管理，因为只需管理角色的权限，而无需单独管理每个用户的权限。

同时，这种方法也保持了一定的灵活性：通过分配和撤销角色，可以轻松地管理用户的访问权限。当用户的职责或权限需求发生变化时，只需调整其角色分配即可。

在安全性方面，RBAC模型可以减少人为错误和误操作的风险。通过严格控制角色的权限，可以确保用户只能执行他们所需的操作，从而减少潜在的安全漏洞。

基于上述特点，RBAC模型被广泛应用于企业环境中，并满足企业或组织内部的权限管理需求，是当今企业级Web应用的主流访问控制模型。

此外，像Github的Personal Access Token(PAT)以及其他互联网Web应用的类似PAT的权限配置也是基于RBAC模型的。使用PAT时，用户可以创建令牌并为其分配特定的范围和权限，这时令牌既是user，也充当了角色(Role)。这些权限可以控制PAT可以访问和执行的操作，例如读取仓库、创建存储库、管理问题等。用户可以根据自己的需求创建多个PAT(Role)，并根据需要撤销或更新它们。下面是github PAT创建和配置的示意图：

不过，RBAC模型虽然是主流模型，但也存在一些问题，比如：

• 静态角色分配

RBAC模型中，角色和权限的分配是静态的，需要预先定义和分配角色。这种固定的角色分配方式难以适应动态变化的访问控制需求。例如，当用户的职责发生变化或需要临时获得额外权限时，RBAC模型需要进行角色重新分配或角色继承的操作，导致管理复杂性增加。

• 角色爆炸问题

在大型组织或系统中，RBAC模型可能涉及大量的角色，以覆盖各种职责和权限。这可能导致角色爆炸问题，即角色数量过多，不易管理和维护。角色之间的关系和权限的粒度也可能变得复杂，增加了配置和管理的复杂性。

• 缺乏细粒度访问控制

RBAC模型的主要限制之一是对访问控制的粒度较粗。RBAC模型通常基于角色来控制访问权限，而忽略了更细粒度的访问控制需求，如基于资源属性、环境上下文等进行访问控制。

• 缺乏动态性和灵活性

RBAC模型的角色和权限分配是静态的，难以适应动态变化的访问控制需求。RBAC模型无法根据实时上下文信息或动态的用户属性来进行访问控制决策，导致难以满足复杂的访问控制策略。

这些问题也促成了00后的新模型ABAC的出现，下面我们就来看看ABAC模型。

2.5 基于属性的访问控制（Attribute-Based Access Control，ABAC)

ABAC，有时也被称为policy-based access control (PBAC)或claims-based access control (CBAC)，是一种基于属性（Attribute）来决定对资源的访问权限的访问控制模型。与“90后”的RBAC模型相比，ABAC模型提供了更细粒度、动态和灵活的访问控制能力。

ABAC模型的核心概念包括如下几个：

• 属性（Attribute）

属性是关于用户、资源、环境或其他上下文信息的特征。属性可以是任意对象，一般有这么几类。访问主体(用户)属性，可以是访问者自带的属性，比如年龄，性别，部门，角色等；动作类属性：比如读取，删除，查看等；被访问对象的属性，比如一条记录的修改时间，创建者等；环境类属性：比如时间信息，地理位置信息，访问平台信息等。属性还可以根据需要进行自定义和扩展。

• 策略（Policy）

策略定义了访问控制规则和条件，用于评估访问请求的属性和上下文信息，并决定是否允许或拒绝访问。策略可以包括属性匹配、逻辑操作、时间条件等。

• 属性策略引擎（Policy Decision Point, PDP）

属性策略引擎是ABAC模型的核心组件，负责评估访问请求的属性和条件，并根据属性和预定义的策略进行逻辑计算，以做出是否允许访问的控制决策。

下面是一个使用ABAC模型在组织内控制对某个文件资源的访问的例子的示意图：

在这个示例中，用户属性包括用户角色（Role）、用户部门（Department）、用户年龄(Age)；资源属性有文件类型（FileType）、文件所属部门（FileDepartment）。

属性策略引擎(PDP)通过PIP(策略信息点)获取相关属性，并基于策略做出决策。下面是一些策略示例：

策略1：仅允许具有"管理员"角色的用户访问任意类型的文件。
策略2：仅允许具有"员工"角色的用户访问属于自己部门的任意类型的文件。
策略3：允许具有"访客"角色的用户访问公共类型的文件。
策略4：允许60岁以上用户访问特定类型的文件。
策略5：不允许访问属于其他部门的文件。

图中的PEP(策略执行点)负责接收用户发起的访问请求，并将请求传递给PDP进行决策，确保访问控制策略得到严格执行，以保护资源的安全性和完整性。用户可以是人员、应用程序或其他实体。之后，PEP负责根据访问控制策略的决策结果来执行实际的访问控制。当PDP（Policy Decision Point，属性策略引擎）确定用户是否被授权访问资源后，PEP将根据决策结果来允许或拒绝对资源的访问。PEP还可以记录和监控访问请求和决策结果，用于后续的审计和安全分析。通过记录访问活动，PEP可以提供有关谁、何时以及如何访问资源的详细信息。

ABAC是较新的访问控制模型，相较于它的前辈RBAC来说，它的能力更强大，控制粒度更精细，授权决策动态且灵活，但也更加复杂，需要定义和管理大量的属性和策略。这可能增加了实施和维护的困难。另外，ABAC模型的属性策略引擎需要对访问请求进行属性匹配和逻辑计算，这可能对系统性能产生一定的影响，在引入ABAC模型时，这也是一个需要考虑的因素。

尽管ABAC模型存在一些挑战和复杂性，但它提供了更高级、动态和灵活的访问控制能力让它可以更好地满足复杂的访问控制需求和安全策略，这使得ABAC模型在许多组织和行业中得到广泛应用，包括企业、政府、云计算、物联网等。同时，有许多标准化组织和机构致力于制定ABAC的标准和规范，例如NIST（美国国家标准与技术研究院）的NGAC和OASIS的XACML（eXtensible Access Control Markup Language），这些标准化努力有助于推动ABAC的统一实施和互操作性。

随着技术的不断进步，ABAC模型也在不断演进和改进。例如，引入了机器学习和人工智能技术来提高决策过程的自动化和智能化。

到这里，我们已经学习了从ACL到ABAC的5种主要访问控制模型，包括它们的发展历史、应用场景、优缺点等，这给我们提供了对不同访问控制模型的全面了解和比较。如今RBAC和ABAC是大家广泛应用的主流模型，接下来，我们就以一个示例来进一步加深这两个模型的理解。我将构建一个简单的公司员工信息管理系统，并在此系统中分别实现基于RBAC和ABAC的访问控制机制，以便通过对比不同实现来直观感受两种模型的区别。

3. 一个Web应用的授权实例

下面我们用一个Web应用的授权实例来进一步理解RBAC和ABAC两个广泛使用的访问控制模型。这是一个公司员工信息管理系统授权访问控制的示例，我们先用casbin以RBAC模型实现该示例，之后使用Open Policy Agent以ABAC模型再实现一遍该示例。

3.1 示例简介

好的，现在给你描述一下这个示例对授权的具体要求。

这是一个公司的员工信息管理系统，系统中定义了几种角色(role)：经理(manager)、员工(employee)、HR和财务(finance)。这些角色可以直接用于RBAC模型中的角色，在ABAC中，它也可以作为主体(subject)的角色属性使用。系统要保护的资源有两个表：员工信息表(employee_info)和员工工资表(employee_salary)，并定义了如下访问控制要求：

• 经理：可以查看和修改所有员工的信息
• 员工：可以查看和修改自己的信息
• HR：可以查看和修改所有员工的信息，可以查看和修改所有员工的工资信息
• 财务：可以查看所有员工的工资信息

这个公司有如下几位不同角色的员工：

• 经理：alice
• 员工：bob
• HR：cathy
• 财务：dan

接下来我们就先来基于RBAC实现该系统的访问控制。

3.2 基于RBAC模型的访问控制

根据前面的介绍，RBAC模型是基于角色的访问控制，因此针对上面示例描述，我们需要先定义角色以及为角色分配权限。

casbin使用policy.csv定义角色的权限：

// authz-examples/rbac/casbin/policy.csv

p, manager, employee_info, read
p, manager, employee_info, write
p, employee, employee_info, write
p, employee, employee_info, read
p, hr, employee_info, read
p, hr, employee_info, write
p, hr, employee_salary, write
p, hr, employee_salary, read
p, finance, employee_salary, read

初看这个文件中的配置数据，很多人不知道是什么意思，这个csv文件中每行的字段含义都要与model.conf对照着看：

// authz-examples/rbac/casbin/model.conf

[request_definition]
r = role, obj, act

[policy_definition]
p = role, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow)) 

[matchers]
m = g(r.role, p.role) && r.obj == p.obj && r.act == p.act

我们看下这个配置文件中的section: policy_definition，我们看到其定义为p = role, obj, act，这里的p就是规则定义，根据这一规则定义，我们可以确定csv中p开头的行中的各段数据的含义，比如：根据“p, manager, employee_info, read”，我们可以得到role=manager，obj=employee_info，act=read，我们用下图再直观总结一下这种对应关系：

request_definition这个section中定义了请求传入时参数的次序(“r = role, obj, act”)，其要求Go代码中调用casbin.Enforcer.Enforce方法时各个参数的传入次序与之相同(比如: Enforce(“manager”, “employee_info”, “read”))，并指示了传入的参数对应的含义。

matchers这个section中定义了匹配规则，先不看g(r.role, p.role)，“r.obj == p.obj && r.act == p.act”这个很好理解，即当请求(request)中的obj与策略规则(policy)中的obj匹配，且请求中的act与策略规则中的act(动作)匹配时，才认为通过访问控制的校验。

我们结合Go代码来看一下casbin对RABC的实现和使用方法：

// authz-examples/rbac/casbin/main.go

package main

import (
    "fmt"

    "github.com/casbin/casbin/v2"
)

func main() {
    users := map[string]string{
        "alice": "manager",
        "bob":   "employee",
        "cathy": "hr",
        "dan":   "finance",
    }

    e, err := casbin.NewEnforcer("model.conf", "policy.csv")
    if err != nil {
        panic(err)
    }

    // 经理alice访问员工信息
    ok, err := e.Enforce(users["alice"], "employee_info", "read") // role, obj, act
    if err != nil {
        panic(err)
    }
    fmt.Println("manager alice can read employee_info:", ok)

    ok, err = e.Enforce(users["alice"], "employee_info", "write")
    if err != nil {
        panic(err)
    }
    fmt.Println("manager alice can write employee_info:", ok)

    // 员工bob访问自己信息
    ok, err = e.Enforce(users["bob"], "employee_info", "write")
    fmt.Println("employee bob can write employee_info:", ok)

    // HR cathy 访问员工信息
    ok, err = e.Enforce(users["cathy"], "employee_info", "write")
    fmt.Println("hr cathy can write employee_info:", ok)
    ok, err = e.Enforce(users["cathy"], "employee_salary", "write")
    fmt.Println("hr cathy can write employee_salary:", ok)

    // 财务dan访问工资信息
    ok, err = e.Enforce(users["dan"], "employee_salary", "read")
    fmt.Println("finance dan can read employee_salary:", ok)

    // 员工bob串改薪水信息
    ok, err = e.Enforce(users["bob"], "employee_salary", "write")
    fmt.Println("employee bob can write employee_salary:", ok)
}

这里只是企业内部信息系统的简化实现，正常情况下，员工使用自己的账号登录到系统后，系统就会获知该用户的角色(role)，这里我们用了一个map来存储用户名与角色的映射关系。

我们基于model.conf和policy.csv创建新的Enforcer，然后调用其Enforce方法并按“role, obj, act”次序传入我们要测试的信息。Enforce返回true表示通过了访问控制规则的验证，否则就是没有通过授权验证。

上述代码的输出结果如下：

$go run main.go
manager alice can read employee_info: true
manager alice can write employee_info: true
employee bob can write employee_info: true
hr cathy can write employee_info: true
hr cathy can write employee_salary: true
finance dan can read employee_salary: true
employee bob can write employee_salary: false

到这里，我们还有一个问题没有解决，那就是casbin的model.conf中role_definition的配置含义以及matchers中g(r.role, p.role)含义。

casbin关于RBAC的文档中明确提到了，如果不使用RBAC模型，那么role_definition就是一个可选的配置；如果要使用RBAC模型，那么role_definition下的每一行都是一个独立的RBAC系统，下面的配置拥有两个独立的RBAC系统：g和g2：

[role_definition]
g = _, _
g2 = _, _

“_, _”表示映射关系中有两方。通常我们只会使用到user和role的映射，因此只用一个RBAC系统即可，即只配置和使用g即可。下面是应用g这个RBAC系统的例子：

// policy.csv
p, manager, employee_info, write
g, alice, manager

这里的“g, alice, manager”的含义是alice是角色manager中的一员，或alice这个user的角色是manager。当然alice这个位置上不仅可以使用user，也可以使用resource，甚至是role，casbin只是将其看成一个字符串而已。

而matchers中的“g(r.role, p.role)”的含义就是请求(r)中的role在policy文件中能找到对应的role。如果Enforce函数传入的是”manager”，那么只有policy.csv中定义了”manager”这个角色，g(r.role, p.role)的结果才是true。

上述示例并未在policy.csv中使用到这种user到role的映射(基于g这个RBAC系统)，下面我们改造一下示例，我们在policy.csv中保存这种user到role的映射，而不是在go代码中保存，新版policy.csv如下：

// authz-examples/rbac/casbin_with_user_in_policy/policy.csv 

p, manager, employee_info, read
p, manager, employee_info, write
p, employee, employee_info, write
p, employee, employee_info, read
p, hr, employee_info, read
p, hr, employee_info, write
p, hr, employee_salary, write
p, hr, employee_salary, read
p, finance, employee_salary, read
g, alice, manager
g, bob, employee
g, cathy, hr
g, dan, finance

对应的Go代码改造如下：

// authz-examples/rbac/casbin_with_user_in_policy/main.go

func main() {
    e, err := casbin.NewEnforcer("model.conf", "policy.csv")
    if err != nil {
        panic(err)
    }

    // 经理alice访问员工信息
    ok, err := e.Enforce("alice", "employee_info", "read") // role, obj, act
    if err != nil {
        panic(err)
    }
    fmt.Println("manager alice can read employee_info:", ok)

    ok, err = e.Enforce("alice", "employee_info", "write")
    if err != nil {
        panic(err)
    }
    fmt.Println("manager alice can write employee_info:", ok)

    // 员工bob访问自己信息
    ok, err = e.Enforce("bob", "employee_info", "write")
    fmt.Println("employee bob can write employee_info:", ok)

    // HR cathy 访问员工信息
    ok, err = e.Enforce("cathy", "employee_info", "write")
    fmt.Println("hr cathy can write employee_info:", ok)
    ok, err = e.Enforce("cathy", "employee_salary", "write")
    fmt.Println("hr cathy can write employee_salary:", ok)

    // 财务dan访问工资信息
    ok, err = e.Enforce("dan", "employee_salary", "read")
    fmt.Println("finance dan can read employee_salary:", ok)

    // 员工bob串改薪水信息
    ok, err = e.Enforce("bob", "employee_salary", "write")
    fmt.Println("employee bob can write employee_salary:", ok)
}

大家看到我们在调用Enforce时，第一个参数传入的不再是role，而是user名字，由于policy.csv中使用g保存了user到role的映射，因此Enforce会在内部将user先替换为映射的role，然后再在policy.csv中找到对应的p定义的role，查看是否满足matchers中“g(r.role, p.role)”规则。

运行上面新示例的结果将于第一个示例一样，这里就不赘述了。

接下来，我们再来看看如何基于ABAC模型实现该公司的员工信息系统的授权。

注：casbin号称也支持ABAC模型，有兴趣的童鞋可以自行基于casbin实现基于ABAC模型的员工信息系统的授权示例。

3.3 基于ABAC模型的访问控制

前面介绍ABAC模型时已经提到过，ABAC是基于属性的访问控制，由于我们这个示例比较简单，能用到的user主体属性只有user的角色(role)，这里就基于user的角色来实现访问控制，而作为客体的那两张表，考虑简单起见，这里并未为之定义什么属性。

OPA（Open Policy Agent）是CNCF基金会下面的一个开源的通用策略引擎，它目前已经从CNCF毕业，也是CNCF目前毕业项目中唯一一个策略引擎。OPA可以用于实现统一的访问控制和策略管理。它提供了一个通用的框架，可用于编写和执行策略，以决定对资源的访问是否被允许。OPA使用一种名为Rego的声明性语言来定义策略。Rego语言简洁而强大，可以表达复杂的访问控制逻辑。它允许开发人员定义规则、条件和约束，以描述访问策略和决策过程。受益于CNCF的支持和资源，OPA获得了更广泛的知名度和认可度。它成为了云原生生态系统中重要的一部分，并与其他CNCF项目和工具进行紧密的集成，如Kubernetes、Envoy、Prometheus等。这种集成加强了整个生态系统的互操作性和一致性，为用户提供了更强大的功能和灵活性。

使用opa实现员工信息系统的ABAC授权，我们需要先使用Rego语言定义出访问控制策略，下面是用Rego定义的员工信息系统的访问控制策略：

// authz-examples/abac/opa/policy.rego

package opa.examples

import input as i

# 定义策略
allow {
  i.subject.role == "manager"
  i.object == "employee_info"
  i.action == "read"
}

allow {
  i.subject.role == "manager"
  i.object == "employee_info"
  i.action == "write"
}

allow {
  i.subject.role == "employee"
  i.object == "employee_info"
  i.action == "read"
}

allow {
  i.subject.role == "employee"
  i.object == "employee_info"
  i.action == "write"
}

allow {
  i.subject.role == "hr"
  i.object == "employee_info"
  i.action == "read"
}

allow {
  i.subject.role == "hr"
  i.object == "employee_info"
  i.action == "write"
}

allow {
  i.subject.role == "finance"
  i.object == "employee_salary"
  i.action == "read"
}

这个策略配置文件使用的语法借鉴了Go，不过即便你不了解Go语法，你很大概率也能读懂其逻辑，是不是感觉比前面的casbin的model.conf和policy.csv的组合配置更易理解一些呢！我们以一个allow代码块为例：

allow {
  i.subject.role == "finance"
  i.object == "employee_salary"
  i.action == "read"
}

这个配置块儿的含义就是当输出的请求中的主体的role为”finance”且客体(resouce)为”employee_salary”并且action为”read”时，允许请求访问。其他的section依此理解即可。

下面我们再来看看基于opa实现上述ABAC模型的Go代码：

// authz-examples/abac/opa/main.go

package main

import (
    "context"
    "fmt"
    "log"

    "github.com/open-policy-agent/opa/rego"
)

func main() {
    // Construct a Rego object that can be prepared or evaluated.
    r := rego.New(
        rego.Query("data.opa.examples.allow"),
        rego.Load([]string{"./policy.rego"}, nil),
    )

    // Create a prepared query that can be evaluated.
    query, err := r.PrepareForEval(context.Background())
    if err != nil {
        log.Fatal(err)
    }

    inputs := []map[string]interface{}{
        {
            "name": "alice",
            "subject": map[string]string{
                "role": "manager",
            },
            "object": "employee_info",
            "action": "read",
        },
        {
            "name": "alice",
            "subject": map[string]string{
                "role": "manager",
            },
            "object": "employee_info",
            "action": "write",
        },
        {
            "name": "bob",
            "subject": map[string]string{
                "role": "employee",
            },
            "object": "employee_info",
            "action": "write",
        },
        {
            "name": "cathy",
            "subject": map[string]string{
                "role": "hr",
            },
            "object": "employee_info",
            "action": "read",
        },
        {
            "name": "cathy",
            "subject": map[string]string{
                "role": "hr",
            },
            "object": "employee_info",
            "action": "write",
        },
        {
            "name": "dan",
            "subject": map[string]string{
                "role": "finance",
            },
            "object": "employee_salary",
            "action": "read",
        },
        {
            "name": "bob",
            "subject": map[string]string{
                "role": "employee",
            },
            "object": "employee_salary",
            "action": "write",
        },
    }

    for _, v := range inputs {
        // Execute the prepared query.
        rs, err := query.Eval(context.Background(), rego.EvalInput(v))
        if err != nil {
            log.Fatal(err)
        }

        if len(rs) > 0 {
            fmt.Printf("%s %s can %s %s: %v\n", (v["subject"].(map[string]string))["role"], v["name"],
                v["action"], v["object"], rs[0].Expressions[0].Value)
        } else {
            fmt.Printf("%s %s can %s %s: %v\n", (v["subject"].(map[string]string))["role"], v["name"],
                v["action"], v["object"], false)
        }

    }
}

这个例子参考了opa官方的示例，我们先基于policy.rego构建一个rego策略引擎，然后按我们的测试逻辑构建一组input，我将input放入了一个map切片中，然后遍历该切片，对每个input执行Eval，通过Eval返回的结果判断input是否通过了引擎的校验。执行上述示例代码，我们将得到：

$go run main.go
manager alice can read employee_info: true
manager alice can write employee_info: true
employee bob can write employee_info: true
hr cathy can read employee_info: true
hr cathy can write employee_info: true
finance dan can read employee_salary: true
employee bob can write employee_salary: false

这个和casbin实现的结果是一致的。

通过上面两种模型的实现，我们能达到相同的效果。不过，opa的rego语言的简洁清晰且不乏强大的表达能力还是让人印象深刻的，casbin的配置在理解上要下一番功夫，并且要用好casbin，还必须要深入理解其配置方法和配置项的含义。这两个工具大家可以根据自己的喜好选择最适合你自己的。

以上无论是RBAC，还是ABAC，都是仅由本地单系统参与的授权模型。随着系统规模的扩大，我们可能需要考虑引入第三方授权系统。第三方授权具有方便实现单点登录、用户友好的授权流程、减少密码传播风险、细粒度的授权管理以及第三方应用程序集成等好处。这些好处可以提供更方便、安全和灵活的用户体验，并促进了应用程序之间的互操作性和集成性。

接下来我们就来说说基于OAuth2的第三方授权。

4. OAuth2授权框架

4.1 什么是第三方授权

在开始理解OAuth2授权框架之前，我们先来简单说说什么是第三方授权。为了更好的说明，我先画了一张示意图：

结合这张图，我们理解以下第三方授权。第三方授权是指一个实体（第三方，比如图中的C应用），通过获得用户的授权，可以访问另一个实体（服务提供者，比如图中的S应用）的资源(比如用户A的一些个人信息)或执行特定操作。在这种授权模式下，用户授予第三方应用程序(C应用)或服务访问其受保护资源(位于S应用中的用户A的一些个人信息)的权限，而无需直接向第三方实体(比如C应用)共享其凭据（如用户名和密码）。

第三方授权的典型示例是用户使用自己的社交媒体账号（如微信、Facebook、Google、Twitter等）登录第三方应用程序或网站：

在这种情况下，用户不需要创建新的账号和密码，而是选择使用其社交媒体账号进行登录。当用户同意授权该应用程序访问其社交媒体账号时，第三方应用程序可以获取用户的基本信息（如姓名、电子邮件地址、头像等）或者在用户的名义下执行某些操作（如发布推文、分享内容等）。下面是使用github和微信对第三方应用进行授权的页面截图：

第三方授权的优势在于用户可以方便地使用现有的身份验证凭据，而无需为每个应用程序创建和记住不同的账号和密码。同时，用户还可以更好地控制其数据的访问权限，选择性地授权应用程序可以访问的资源和操作。需要注意的是，第三方授权的安全性和隐私保护至关重要。用户应该仔细审查并理解第三方应用程序请求的权限范围，并只授权其信任的应用程序访问其敏感信息或执行敏感操作。服务提供者也应该采取适当的安全措施，确保用户的数据得到妥善保护。

这样的第三方授权在移动互联网应用领域十分常见，如果没有一套标准的授权框架，这种授权方式将很难实现。OAuth正是为了解决这个问题而诞生的一个标准的授权框架。接下来，我们就进入OAuth协议框架。

4.2 OAuth协议框架

OAuth协议(全称Open Authorization)的产生是为了解决无须共享密码的情况下，从第三方应用程序(比如前面图中的S应用)安全地访问受保护数据、资源的问题。OAuth是一种行业标准的授权框架，它在第三方应用授权中发挥重要作用。OAuth协议的最新版本为OAuth2.0，并已经被广泛用于各厂家的互联网应用中。在原理上，OAuth2允许用户授权第三方应用，访问该用户在某服务平台存储的资源，而无需共享用户名和密码。它通过“访问令牌(access token)”实现授权。

注：从上述描述我们也能看出：所谓第三方授权其实是将身份认证与授权合为一体的一种机制，以授权为主要目的。因此OAuth被称为授权协议，而不是身份认证协议。

在OAuth协议的核心规范中，对于OAuth的授权流程定义了不同的角色，通过不同角色之间不同概念的信息传递对象的交互，完成整个授权流程。这些角色包括：

• 资源所有者（Resource Owner）

资源所有者是指受保护资源的所有者，当受保护资源被访问时，需要此所有者授予访问者访问权限。如果资源所有者是一个自然人时，即表示为最终用户(比如前面图中的用户A)。

• 资源服务器（Resource Server）

资源服务器是指托管接受保护资源的服务器(比如前面图中的S应用)，接收访问请求并使用访问令牌保护受保护的资源。

• 客户端（Client）

这里客户端通常是指代理用户发起受保护资源请求的客户端应用程序，比如前面图中的C应用。

• 授权服务器（Authorization Server）

客户端通过认证后，授权服务器(比如前面图中的S应用)会向客户端发布访问令牌并获得授权。

访问令牌是客户端应用程序访问受保护资源的凭据，没有访问令牌则无法访问受保护的资源。此令牌通常是授权服务器颁发的具有一定含义的字符串，包含此次授权的基本信息、授权范围、授权有效时间等信息。

授权过程与我们前面的示意图十分相似，结合OAuth协议定义的不同角色，我们借鉴下面示意图再来描述一下基于OAuth2的整个授权流程：

• 步骤1：客户端应用程序向资源所有者发送授权请求，这里的客户端是指普通的WebAPI、原生移动App、基于浏览器的Web应用以及无浏览器的嵌入式后端应用，在流程中充当用户行为代理(比如前图中的C应用)。
• 步骤2：资源所有者(比如前图中的用户A)同意授权客户端访问资源，即获得资源所有者的授权凭据，包含授权范围和授权类型。
• 步骤3：客户端使用上一步获得的授权凭据，向授权服务器进行身份认证并申请访问令牌Access Token。
• 步骤4：授权服务器对客户端进行身份认证，确认身份无误后，下发访问令牌AccessToken。
• 步骤5：客户端使用上一步获得的访问令牌Access Token，向资源服务器申请获取受保护的资源。
• 步骤6：资源服务器确认访问令牌Access Token正确无误后，向客户端开放所访问的资源。

OAuth协议核心文档定义了资源所有者给予客户端授权的4种方式：

• 授权码（authorization code）

这种方式下，第三方应用先申请一个授权码，然后再用该码获取令牌。

• 隐藏式（implicit）

适用于没有后端的纯前端应用，客户端直接获得访问令牌Access Token，而无须客户端授权码这个中间步骤。

• 密码式（password）

资源所有者的认证凭据（即用户名和密码）直接告诉第三方应用，该应用随即使用密码申请令牌。

• 凭证式（client credentials）

适用于没有前端的命令行应用，即在命令行下请求令牌。采用客户端自己的凭据，而不是用户的凭据来作为授权依据，获取资源的访问权限。

在这四种授权方式中，授权码是OAuth协议中主要的授权流程，相比其他的授权模式，其流程最为完备，适用于互联网应用的第三方授权场景。

由于OAuth授权相对较为复杂，涉及角色和环节很多，很难用一个例子将其全貌展现出来，这里就不举代码示例了。如果你的系统并不涉及到第三方，既不为第三方提供服务，也不使用第三方的服务，那引入OAuth 2.0其实就没必要。

5. 小结

本文首先介绍了授权的相关概念，着重说明了授权与访问控制的紧密联系和些许差别。之后，我们对5种常见的访问控制模型逐一做了说明，包括它们的使用场景与优缺点。为了帮助大家更好地理解当今主流使用的RBAC和ABAC模型，我还将一个示例分别用casbin和opa作了实现。

在文章的最后，我们简单介绍了用于第三方授权的OAuth授权框架，包括它的协议中涉及的主要角色以及资源所有者给予客户端授权的4种方式，大家可以根据自己的理解，自行基于像微信或github这样的支持三方授权的应用编写一些简单示例。

本文示例所涉及的Go源码可以在这里下载。

6. 参考资料

• 《API安全实战》 – https://book.douban.com/subject/36039150/
• 《API安全技术与实战》 – https://book.douban.com/subject/35429043/
• 授权（上）：系统如何确保授权的过程可靠？ – https://time.geekbang.org/column/article/331411
• 授权（下）：系统如何确保授权的结果可控？ – https://time.geekbang.org/column/article/332255
• Authorization Cheat Sheet – https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
• Acess Control(owasp) – https://owasp.org/www-community/Access_Control
• Web App Access Control Design – https://owasp.org/www-pdf-archive/ASDC12-Access_Control_Designs_and_Pitfalls.pdf
• OPA: The Cloud Native Policy Engine – https://www.slideshare.net/TorinSandall/opa-the-cloud-native-policy-engine
• ACL模型 – https://en.wikipedia.org/wiki/Access-control_list
• MAC模型 – https://en.wikipedia.org/wiki/Mandatory_access_control
• DAC模型 – https://en.wikipedia.org/wiki/Discretionary_access_control
• RBAC模型 – https://en.wikipedia.org/wiki/Role-based_access_control
• ABAC模型 – https://en.wikipedia.org/wiki/Attribute-based_access_control
• Open Policy Agent Introdution – https://www.openpolicyagent.org/docs/latest/#5-try-opa-as-a-go-library
• Casbin: Syntax for Models – https://casbin.org/docs/syntax-for-models
• OAuth 2.0 的四种方式 – https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
• OAuth – https://en.wikipedia.org/wiki/OAuth

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。