好书推荐：

《F5 API 安全网关》

作者介绍：

林健

F5 Networks 资深技术专家，职业生涯前期从事系统开发数据库调优，应用交付领域相关工作12年，获得F5 101-304全系列产品认证证书。林健具备丰富编程以及软件化相关知识，主持过Ansible/K8S/Spring/BIG-IQ等多个F5内部专题小组，成功帮助客户实施基于F5产品的应用多中心部署方案，多容器集群解决方案，公有云入口安全解决方案。林健致力于部署创新性项目，充分发挥F5的产品优势打造下一代软件定义的基础架构和应用架构。

徐世豪

F5 Networks 资深安全专家，从事应用交付领域相关工作九年，专注于为国内银行业客户提供应用交付及安全架构的咨询与设计，曾参与到多起安全事件的对抗工作中。针对DDoS攻防，机器人攻防、WEB应用安全及业界安全趋势等方向有深入了解，并基于F5安全产品特性与理念为客户提供完整的一体化WEB应用安全解决方案。

本书适合阅读人群：

CIO，开发架构师，PaaS架构师，API管理系统开发人员，安全工程师，面向转型的数据中心网络运维人员等。

 本书特色：

本书非系统化的向读者阐述了API生态环境、构成组件及功能特性，使读者对API管理系统以及API网关可以有清晰的了解，同时也阐述了F5 软件以及硬件产品在API系统中的角色，详细描述F5作为API网关的各功能实现以及特色，为客户通过F5实现API Gateway提供指导。

 目录：

本书共分6期，会不定期在“F5数字图书馆”社群发布。

第二篇：API网关之认证篇

API 领域广泛使用了几个方面的认证技术，诸如Oauth2，OpenID，JWT等等，Oauth2本身的流程如下：

Oauth2的实际效果是，资源所有者通过该流程赋予第三方应用访问资源服务器的有限权限，该模式被广泛应用在社交网络提供用户认证登陆服务，比如通过使用微信账号登陆微博等其他社交媒体，微博可以获取到用户在微信上的头像等相关信息：

上述登陆过程中会使用到Callback URI，以及Authorization Code等认证流程细节技术，服务于to C的场景，而在API Gateway的认证中，虽然也是授权第三方应用访问资源服务器，但是是一个to B的场景，第三方通过制定的门户或者流程获取

相关秘钥/密码即可，一个典型的认证场景是AWS 的自身的API接入：

在AWS账户中可以生成一个access key，使用该key以及该key对应的secret，可以调用AWS 的API对AWS账户下的资源进行操作。

我们回到序章的架构图，AWS的Console可以理解为管理门户：

在一个通用型的API系统中，API调用者作为第三方服务器调用API服务器，API的使用者可以通过管理门户得到一个Token，使用这个Token发起API请求到API网关，API网关将识别该认证信息，并将请求转发到适当的API服务器组，此时API系统各组件在认证关系中可以理解为：

  API网关+API服务器=资源服务器

Oauth2的RFC本身自定义了认证流程中的各个角色，对于Token的认证使用RFC7662进行定义，该RFC提出是通过在请求中夹Token，资源服务器请求认证服务器获取到Token的SCOPE，该SCOPE可以是自定义的任何值，经典Oauth2的请求在该RFC有范例：

POST /introspect HTTP/1.1

     Host: server.example.com

     Accept: application/json

     Content-Type: application/x-www-form-urlencoded

     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=mF_9.B5f-4.1JqM&token_type_hint=access_token

范例返回如下：

HTTP/1.1 200 OK

     Content-Type: application/json

     {

      "active": true,

      "client_id": "l238j323ds-23ij4",

      "username": "jdoe",

      "scope": "read write dolphin",

      "sub": "Z5O3upPC88QrAjx00dis",

      "aud": "https://protected.example.net/resource",

      "iss": "https://server.example.com/",

      "exp": 1419356238,

      "iat": 1419350238,

      "extension_field": "twenty-seven"

     }

另外，RFC强调response可以出于提高性能的要求被cache，同时跟随Token提交的信息只有一个token_type_hint，这显然不符合API网关中，一个入口点服务器多个API资源服务器的场景，我们来看看Google自身的API是怎么做的,根据Google API的文档描述

总结一下，自建API服务的过程中有两种认证路线：

1.      普通Bearer Token + SCOPE Valid（要看Oauth2认证服务器是否支持）

2.      基于Json Web Token（JWT）的Token

两种Token的区别在于，Bearer Token本身并不包含太多的信息，需要将token转发到Oauth2服务器进行验证，而JWT在Token本身已经包含了足够的信息，可以在资源服务器上直接验证，两者在技术上无高下之分，只是适配的场景不同。

Bearer Token可以结合Scope对请求内容+Token发给认证服务器，此时API网关需要Cache 认证结果，避免业务压力直接扩散到认证服务器，对Token的撤销时效性较快，API KEY本身和API可以采用松耦合关系，但是对oauth2认证服务器的要求比较高。

JWT  Token无需转发给认证服务器，但是需要消耗更多的CPU资源做Token的解密工作，另外对Token撤销需要更新服务器侧的Key配置或Token配置，时效性略低，但是开发起来可以抛弃oauth2的设计考虑，只单纯考虑如何update API网关的加密Key（非API key）列表即可。

F5 APM同时支持上述JWT认证以及Beare Token的Scope valid，同时 Per API选择各自的认证方式，也支持同一个API请求使用同时使用HTTP基础认证以及Oauth2认证，整体认证部署如下：

F5对API整体认证流程如下：

通过上述流程可以总结出F5 在认证功能中的一些特色：

Per API认证

F5支持对在同一入口对不同的API使用不同的认证。

如上图，可以实现对特定API入口：POST /dev执行认证检查，对其他API入口不做任何认证

混合认证

 对于同一个API入口，可以自动识别认证种类，实现对API的混合认证。

在上图中，对某个API的请求，如包含HTTP Basic的相关报文头，则识别为HTTP Basic认证类型请求，将用户名和密码提交给LDAP服务器进行认证，如包含Oauth Bearer报文头，则执行Oauth相关的认证步骤。

JWT 类型Token细粒度校验

根据Token 字段校验Token合法性，撤销Token可以更细粒度执行，比如撤销特定类别的Issuer/ Audience，撤销指定某个Token，对比开源的解决方案，粒度更精确，无需撤销某key下所有token,对Key管理有很好的便利性。

增强型Bearer Token认证

Per API的Token认证和Token Cache，支持Scope校验，Scope重写，实时性更强，已经内置大多数互联网API服务认证提供商的SCOPE认证内置模版。

支持基于OpenID的JWK自动获取

F5作为资源服务器的前端，支持基于OpenID协议的JWK自动获取并且自动update到相关Token配置，实现全自动JWT KEY撤销修改。

总结：

在API管理系统中，F5可以作为Oauth2服务器以及资源服务器的统一认证代理，具备完整的认证流程，支持多种认证方法以及灵活的Token/Key撤销机制，可以满足不同客户的多种API认证需求，提供领先的API认证功能并且降低整体开发成本。

后记：

估计你们会问，为什么要来F5数字图书馆看书？

经典的书，你买过的书，也许很多很多，你看完并且吃透的书呢？

也许有优秀的“书”我们还没好好读，也许我们有好多的书想分享却找不到那个对的人，也许阅读时有深深的困惑却无人能解答……

来F5书架吧，利用你的碎片时间，丰富大脑，提升技术，充实灵魂。这里你不仅仅能看书，还能答疑解惑，还可以和志同道合的朋友高谈阔论，还可以互相切磋获得灵感……