API Tokens
SAML
这里列出4种，首先简单介绍下，然后一一叙述。
第一种，使用HTTP Basic Auth协议，加上独立的Auth数据库。
第二种，也是使用HTTP Basic Auth协议，跟第一种不同的是，使用集中式的Auth数据库
第三种，API Tokens协议，这种大家应该比较熟悉，很多公有服务(比如Github、Twitter等)的API都是用这种方式。
第四种，SAML，即Security Assertion Markup Language，翻译过来，是『安全声明标记语言』，它是基于XML的一种协议，企业内使用得较多。
下面一一做介绍。
微服务常用访问安全设计方案——Basic Auth + Independent Auth DB
第一种，如上示意图所示，使用Basic Auth协议，配合每个服务自己都拥有存储Credential敏感数据的数据库(或者其他持久化仓库)。
简单介绍下Basic Auth协议，它是在用户的请求中添加一个Authorization消息头，这个消息头的值是一个固定格式：
Basic base64encode(username+“:”+password)
完整的消息头列子为：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Basic Auth协议基本上被所有流行的网页浏览器都支持。
这种方案的特点：
每个提供功能的服务都拥有自己独立的鉴权和授权机制
每个提供功能的服务都拥有自己独立的数据库，来保存敏感信息
每次用户请求都需要携带用户的credential来完成操作
小结下使用这种方案的好处：
微服务的应用可以实现100%无状态化
基于Basic Auth开发简单
同时，小结下使用这种方案需要注意的地方：
由于每个服务都有自己存储credential的机制，需要事先为每个服务设计好如何存储和查找用户的Credential
由于每次用户请求都会携带用户的Credential，需要事先设计好如何管理鉴权机制
微服务常用访问安全设计方案——Basic Auth + Central Auth DB
第二种，如上示意图所示，使用Basic Auth协议，与第一种方案相比，每个服务共用有同一个Auth DB。
第二种方案的特点和第一种很相似：
每个提供功能的服务都拥有自己独立的鉴权和授权机制
每个提供功能的服务共用同一个DB，来保存Credential等敏感信息
每次用户请求都需要携带用户的credential来完成操作
小结下使用第二种方案的好处：
除了拥有第一种方案相似的好处外，由于共用了同一个持久化仓库来管理用户信息，简化了原来独立管理的机制
同时，小结下使用这种方案需要注意的地方：
中心化Auth DB会被每次用户请求来访问连接，可能引发AuthDB性能瓶颈
需要在每个服务中实现对共有Auth DB查找用户信息的逻辑
微服务常用访问安全设计方案——API Tokens
第三种，如上示意图所示，使用Token Based协议来对用户请求进行操作鉴权。
简单介绍下最基本的Token Based的交互方式：
用户使用包含用户名和密码的credential从客户端发起资源请求
后端接受请求，通过授权中心，生产有效token字符串，返回给客户端
客户端获得token后，再次发出资源请求
后端接受带token的请求，通过授权中心，获取相关资源，返回给客户端
业界常用的OAuth就是基于Token Based这套逻辑，实现的互联网级的鉴权机制。
第三种方案的特点明显：
使用token来进行鉴权，替换用户本身的用户名和密码，提高了交互安全性
每次用户请求需要携带有效token，与Auth服务进行交互验证
小结下使用第三种方案的好处：
由于使用了token来鉴权，业务服务不会看到用户的敏感信息
同时，小结下使用这种方案需要注意的地方：
Auth服务可能需要处理大量的生产token的操作
微服务常用访问安全设计方案——SAML