一、微服务面临的挑战（为什么要提出微服务的安全？）
- 攻击面变广，攻击风险变高（在部署中管理10个，15个或数百个独立的微服务将有多困难？成千上万个微服务怎么进行安全管理？）
- 多次安全检查，可能会导致性能问题
- 微服务间的信任变得复杂
- 微服务的分布式特征，使共享用户会话变得困难
- 多语言架构,需要更多的安全专家
二、主流安全机制，保护微服务安全的一些常见技术
2.1 边界安全
执行边界安全是保护微服务的一种非常传统的方法。 这意味着单个微服务不安全;访问微服务的层必须是受信任的。对Web应用程序的访问是安全的，并且Web应用程序自由地调用微服务层。各个微服务彼此自由交互。有一些与微服务相关的特性和要求使得边际的安全性不足。
1.由于各种原因，应在每个服务执行认证或授权。
2.每个细粒度的服务是一个小团队的责任。 这可能意味着保证数据的安全性也是他们的责任。
2.2 用户身份认证（用户名和密码）
在微服务体系架构中，微服务应用是由多个相互独立的微服务进程组成的，对每个微服务的访问都需要进行用户认证。
微服务应用应遵循单一职责原理，即一个微服务只处理单一的业务逻辑。认证和鉴权的公共逻辑不应该放到微服务实现中。因此需要考虑一个抽象、公共的逻辑对用户进行身份认证和鉴权服务。由于在微服务架构中以API Gateway作为对外提供服务的入口，因此可以考虑在API Gateway处提供统一的用户认证。
具体就技术实现采用Zuul+Spring Security+OAuth2/JWT。
在这种方法中，每个微服务将使用BasicAuthentication进行保护。 有几种方法来实现这一点。
1.最终用户凭据。 在这种情况下，每个微服务需要最终用户的用户名和密码来执行认证或授权。 当应用程序调用微服务或微服务调用另一个微服务时，它必须传递最终用户的用户名和密码。 这种方法有很多安全隐患。
2.每个微服务都应该有权访问最终用户凭证存储。
3.用户名和密码必须由每个服务被存储在存储器或会话，以便当一个微服务正在呼叫另一个微服务时使用。
4.受信任的子系统凭据。 用户名和密码用于受信任的子系统（例如，系统中的每个实体都有一个凭据集）。这种方法的缺点是最终用户是未知的，因此不能执行授权。如果一个实体更新凭证，会发生什么？ 如果凭据保存在文件中，则应在每个实例中更新此文件。
2.3 双向SSL
在此安全机制中，系统中的每个实体都有一个证书（公共和私有）密钥对，并使用双向SSL彼此通信。、在正常的SSL场景中，服务器由客户端进行身份验证，但在双向SSL中，双方都彼此进行身份验证。 、与最终用户用户名和密码方法相比，这是一个更好的方法，因为风险很小。
然而，这种方法的一些缺点在下面给出。
（１）每个微服务都需要一个证书，所以当更新证书时，更新需要在所有实例中进行。
（２）最终用户不能在此模式下授权或认证。
（３）它具有与可信子系统模式类似的优点和缺点。
2.4 OAuth 2.0 OpenID Connect
OAuth 2.0是一个应用之间彼此访问数据的开源授权协议，所以OAuth不是一个API或者服务，而是一个验证授权(Authorization)的开放标准，所有人都有基于这个标准实现自己的OAuth。
微服务可以使用OAuth 2.0以及OpenID连接来验证和授权用户。有一个IdP提供方向请求方提供OAuth 2.0令牌。 例如，应用程序获得OAuth 2.0访问令牌，并且访问此令牌用于调用MSA中的所有服务。 它也可以用于微服务之间的通信。 使用短寿命访问，令牌简化并提高整个系统的安全性。 使用OpenID连接，可以检索最终用户的身份，允许微服务执行授权本身。
然而，这种方法的缺点是对IdP额外方的调用。
（ 身份提供商（IdP）是一种存储和验证用户身份的服务。IdP 通常是云托管服务，常常与单点登录（SSO）提供程序搭配来验证用户的身份。）
2.5 自包含的JWT令牌
这是一种最合适的微服务安全方式。
自包含JWT令牌是在令牌本身内具有授权信息，即令牌由发行者签名，并且所有各方可以验证令牌的有效性。
这意味着微服务不需要调用外部方来验证访问令牌并获得JWT令牌。消除了验证接入令牌并获得承载令牌的附加呼叫。
它具有OAuth2.0的所有优点，但不具有短寿命标记的缺点。
1，强制下线等对客户端控制的问题
2，Token被抓包导致的安全风险