文章目录
- 前言
- 一、微服务安全设计原则
- 二、微服务常见的认证方案
- 1.分布式Session
- 2.API Tokens
- 3.JWT
- 4.Oauth2
- 5.Spring Cloud Security解决方案
- 总结
前言
主要探讨一下在微服务架构下的一下安全设计方面的内容，包括JWT、OAuth2.0以及如何使用Spring Cloud Security实现保护服务接口、服务间的鉴权等。
我们也要知道认证和授权的区别：“认证”：解决了你是谁的问题、“授权”：就是你能干什么，这就是比较通俗的说法。
一、微服务安全设计原则
微服务安全是在实际应用中的一个很普遍要求，安全主要关心调用者是谁， 调用者能干什么， 以及如何传播这个信息，也就是常说的服务间的认证和授权。
- 单点登录：微服务架构下，实现用户只需要登录一次就能访问所有相互信任的应用系统。
- 无状态：前后端分离，后端不保存用户Session，每次请求都要鉴权。
- 细粒度：每个组件管理自己的功能权限，需要实先确定好权限。
- 非浏览器客户端的操作性：需要考虑到那些非浏览器端的客户请求，对其提供良好的支持。
二、微服务常见的认证方案
1.分布式Session
传统的单体应用的session，在Spring cloud微服务架构下，可以采用分布式session机制，可以将用户的认证信息存储在共享存储（如redis）中，用户会话作为key实现简单的分布式哈希映射，当用户访问微服务时，用户数据可以从共享存储中获取。Spring Session对分布式Session提供了支持，也与Spring Boot/Cloud无缝集成。
2.API Tokens
随着 Restful API、微服务的兴起，基于 Token 的认证现在已经相当普遍了。
Token一般会包含用户的相关信息，其它微服务可以从Token里提取出用户、权限等信息完成鉴权。
3.JWT
JSON Web Tokens（JWT）是一种认证协议，是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（RFC 7519）。JWT 一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该 Token 也可直接被用于认证，也可被加密。
授权服务器将用户信息和授权范围序列化后放入一个JSON字符串，然后使用Base64进行编码，最终在授权服务器用私钥对这个字符串进行签名，得到一个JSON Web Token。
假设其他所有的资源服务器都将持有一个RSA公钥，当资源服务器接收到这个在Http Header中存有Token的请求，资源服务器就可以拿到这个Token，并验证它是否使用正确的私钥签名（是否经过授权服务器签名，也就是验签）。验签通过，反序列化后就拿到Toekn中包含的有效验证信息。
4.Oauth2
OAuth是一个关于授权（authorization）的开放网络标准，在业界得到广泛应用，目前的版本是2.0版。
简单来说就是客户端应用程序（通常是web浏览器）代表用户（得到了用户的批准）去访问受保护的资源。
5.Spring Cloud Security解决方案
spring Cloud Security包含了Spring Security和Spring Security Oauth
- 基于OAuth2 和 OpenID协议的可配置的SSO登录机制
- 基于tokens保障资源访问安全
- 引入UAA（User Account and Authentication）鉴权服务，UAA是一个Web服务，用于管理账户、Oauth2客户端和用户用于鉴权的问题令牌(Issue Token)
实现了Oauth 2授权框架和基于JWT(JSON web tokens)的问题令牌。
基于OAuth2，当用户访问客户端应用时，生成并发放token给目标客户端。
主要内容：
- 认证对象：如用户、客户端以及目标资源服务器
- 认证类型：主要有授权码模式、密码模式以及客户端模式
- 认证范围：即认证权限，并作为一个命名的参数附加到AccessToken上
总结
总的来说，微服务架构下，分布式Session、Spring Cloud Security都可以作为安全设计的方案，分布式Session虽然可以解决，但实现起来相对复杂，终究不是上策。Spring Cloud Security很好的结合了Oauth2.0、JWT，加上简单易用，能有效地提高后端服务的可用性和扩展性，能很好的满足微服务架构的安全需求。
