前言

到现在为止，我从事专业软件开发工作已经20年了，而且这些年，我用过各种各样的API。在我年轻的时候，曾经用BASIC语言和少量Z80机器代码编写过冒险游戏软件，那时根本不用担心有人会使用我的代码，更不用说通过接口调用代码了。直到1999年我以大学预科生的身份（有人亲切地称之为pooeys）加入IBM，我才第一次遇到供他人使用的代码。我记得某年夏天，我大胆地尝试将一个C++网络库集成到一个测试框架中，其间原作者通过一个简短的邮件对我进行了指导。在那个时候，我更关心的是如何破译那些难以捉摸的编译器错误信息，几乎不去考虑安全性问题。

随着时间的推移，API在概念上已经转变为涵盖可远程进行调用的接口了，而这时安全性就不再那么轻易地被忽略了。逃离令人恐怖的C++，我又置身于EJB（Enterprise Java Bean）的世界中，这里充斥着大量远程API调用以及数目众多的接口和样本程序。我几乎想不起来在那段日子里我用接口程序构建了什么，只知道这些代码程序是极其重要和必不可少的。之后，我们以SOAP和XML-RPC的形式添加了大量XML数据。但这没什么用。后来RESTful API和JSON的出现带来了一股清流：API最终变得非常简单，这时你就会有时间去考虑哪些接口是可以对外开放的。也正是在这个时候，我开始对安全产生了兴趣。

2013年，我入职ForgeRock，这是一家刚刚从Sun Microsystems[1]的废墟上重新站立起来的初创公司。当时该公司正忙于为其管理产品编写认证和授权REST API，我正好加入了进来。在此过程中，我快速掌握了最新的基于令牌的授权和认证技术，这些技术在最近几年改变了API的安全性，本书很大一部分内容也来源于此。当Manning出版社建议我写一本书的时候，我马上就想到了要以API安全为主题来写这本书。

本书的大纲几经修改，但我始终坚持安全领域重在细节的原则。你不可能仅通过添加标记为“身份认证”和“访问控制”的外包装，就实现纯粹的架构级别的安全性。你必须确切地理解你要保护什么，以及这些“外包装”能够保证什么和不能保证什么。另外，安全领域也不适合那些零基础的读者。在本书中，我希望我们能够顺利地进入这样一个阶段——我能够为你解释清楚为什么事情是这样的，并提供许多常见安全问题的解决方案。

我坚持的另一个原则是安全技术并不是一劳永逸的。适用于Web应用程序的安全技术很可能根本不适用于微服务架构。依据我的经验，本书按照Web应用、移动客户端、Kubernetes环境下的微服务，以及物联网API等章节来分别阐述API安全。每个领域都有其自身的挑战和解决方案。

[1] Sun Microsystems是一家1982年创立的互联网技术服务公司，后被甲骨文收购。——译者注