微服务架构下认证和鉴权理解

认证和鉴权

从单体应用到微服务架构，优势很多，但是并不是代表着就没有一点缺点了。

微服务架构，意味着每个服务都是松散耦合的。因此，作为软件工程师和架构师，我们在分布式架构中面临着安全挑战。微服务对外开放的端点，我们称之为：API。

• 单体应用只需要保护自己就可以了，而微服务的攻击面则很大，这意味着越多的服务将会带来更大的风险，每个服务都得保证其安全性。
• 在单体架构中，组件之间通过方法来相互调用。而微服务则是依靠开放的API来相互调用，除了要保证其安全性，还得保障其可用性。

因此，根据上述的安全挑战，我们可以得出一个结论：微服务与单体应用有着不同的安全处理方式。

认证和授权的区别

我们在谈论应用程序安全的时候，总是会提到：认证 （Authentication）和 鉴权 （Authorization）这两个术语。但是，总有人很容易混淆概念。

在 身份验证（Authentication） 的过程当中，我们需要检查用户的身份以提供对系统的访问。在这个过程当中验证的是 “你是谁？” 。故而，用户需要提供登陆所需的详细信息以供身份的验证。

授权（Authorization） ，是通过了身份验证之后的用户，系统是否授权给他访问特定信息（读）或者执行特定的操作（写）的过程。此过程确定了 用户拥有哪些权限。

微服务下的认证和授权策略

可以想到的解决方案有以下这么几种：

• 无 API 网关
  1. 每个服务各自为政，各自进行认证和鉴权
  2. 拆分出 认证授权服务 进行全局的认证和鉴权
• 有 API 网关
  1. 在网关上进行全局的认证，每个服务各自鉴权
  2. 在网关上进行全局的认证和鉴权
  3. 拆分出 认证服务 进行全局的认证，在网关上进行鉴权

比较推崇 有 API 网关-3 这种策略，为什么呢？

1. 认证对于鉴权来说，是频度较低的服务：登陆不常有，鉴权则发生在每一个API调用上；
2. 往往认证会相对复杂，具有特异性，难以做到通用化。而鉴权不会特别复杂，容易做到通用化。

有状态和无状态身份验证

当一个设备（客户端）向一个设备（服务端）发送请求的时候，服务端如何判断这个客户端是谁？传统意义上的认证方式又两种：有状态认证、无状态认证。有状态认证和无状态认证最大的区别就是服务器会不会保存客户端的信息。

有状态身份验证
有状态认证，以cookie-session模型为例，当客户端第一次请求服务端的时候，服务端会返回客户端一个唯一的标识（默认在cookie中），并保存对应的客户端信息，客户端接受到唯一标识之后，将标识保存到本地cookie中，以后的每次请求都携带此cookie，服务器根据此cookie标识就可以判断请求的用户是谁，然后查到对应用户的信息。

无状态身份验证
无状态的认证，客户端在提交身份信息，服务端验证身份后，根据一定的算法生成一个token令牌返回给客户端，之后每次请求服务端，客户端都需要携带此令牌，服务器接受到令牌之后进行校验，校验通过后，提取令牌的信息用来区别用户。

总结

本文介绍了服务在从单体演进到微服务架构过程中，对于服务认证鉴权遇到的问题，并提供了开发人员可能会用到的解决方案。如今微服务架构已经成为事实上的标准，我们希望微服务一定是无状态的，专注于处理业务流程和规则，而鉴权认证的逻辑应交给专门的技术组件来负责，因此让网关来统一处理鉴权是一个更优雅的方案。

参考

Kratos微服务框架下的认证和鉴权