聊聊微服务安全之认证与授权_rfc 7616 java-优快云博客

本文链接：https://blog.youkuaiyun.com/bin_yu/article/details/95738386

本文探讨了微服务架构下的认证与授权，包括基本概念、认证技术（如IWA、HTTP Basic、Digest、Form、SSL客户端认证、HMAC）、单点登录技术（SAML、OAuth2、OpenID Connect）、授权技术和会话管理（基于Session和Token）。文章强调了微服务时代认证授权的挑战，提出服务化、元数据集中管理和内部统一身份凭证等最佳实践。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

引言

如今微服务架构已经是互联网应用的事实标准。相比传统单体应用，微服务架构给我们带来了诸多好处：快速迭代、松耦合、独立部署、高可靠、技术栈选择灵活等等，但与此同时它也给我们引入了分布式系统的复杂性和由此带来的各种挑战。其中一个挑战就是如何在微服务架构下保证应用访问的安全。

应用安全是个很宽泛的领域，本文将只讨论认证和授权。相对于单体应用，微服务架构下的认证和授权涉及的场景更多更复杂：用户访问、外部系统调用、微服务内部调用等。如何针对各种场景设计一整套灵活、安全、高效的认证和授权方案对微服务开发者来说无疑是个巨大的挑战。

基本概念

认证和授权是两个不同的概念，却很容易被混淆。理清他们的职责范围和关联关系有助于开发者进行清晰的架构思考与设计。

认证

认证（authentication）是指用户证明自己身份的过程，它解决的是 “我是谁？”的问题。一般应用系统里面会给每个用户分配一个UID，在这个应用系统中UID就代表用户的身份，决定了该用户能做什么和不能做什么。但光有UID还不够，因为谁都可以声称自己是该UID的主人，所以用户在登录应用系统的时候除了出示UID，还要出示密钥(credential)，只有当出示的密钥和用户注册时设置的密钥匹配的时候才算认证通过。

授权

授权（authorization）则是指用户证明自己身份后，应用系统进一步判断用户可以访问哪些系统资源的过程，它解决的是“我能做什么？”的问题。授权往往是伴随认证来完成的。

会话管理

由于HTTP是无状态的，请求与请求之间相互独立，所以用户登录后必须要使用一种方式来记住这个登录的状态，并且把这个用户的一连串的交互请求关联起来，这样用户就不必每个请求都带上密钥了，这就是会话（SESSION）的最大作用。当然会话还可以存储其他用户的信息，比如语言偏好、时区设置等，这里只关注其在用户认证和授权方面的作用。因此，一般来说一套完整的认证和授权方案应当包含三个部分：用户认证、会话管理和权限检查（如下图所示）。

认证技术

针对Web应用，近十几年来业界出现过很多认证方法，下面列举一些常用的：

Integrated Windows Authentication (IWA)

微软出品，与Windows账号体系（包括AD）完美结合，使用它用户可以以Windows用户的身份来自动登录你的应用，它能给Windows用户提供了一个比较好的单点登录的体验。它的底层支持Kerberos /NTLM协议，细节请参考官方文档，这里就不介绍了。以前IIS盛行的时候用的比较多，现在淘汰的差不多了。

HTTP Basic

这种方式以前用的比较多，比如好多古老的路由器登录的时候都会弹出下图这样的登录框，那就是使用的HTTP Basic认证：

这个协议通过HTTP头携带Base64编码后的用户名密码，示例：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

细节请参考rfc7617。

这种方式实现起来非常简单，当然缺点也很明显，Base64 只能称为编码，而不是加密，所以最好使用HTTPS传输。现在基本没有Web应用采用HTTP Basic认证了，但还可以把它用于内部API调用的认证。

HTTP DIGEST

摘要认证是针对Basic认证存在的诸多问题而进行的改良方案，主要通过传递用户名，密码等计算出来的摘要来解决在网络上明文发送密码的问题，示例：

Authorization: Digest username="Mufasa",

realm="http-auth@example.org",

uri="/dir/index.html",

algorithm=MD5,

nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",

nc=00000001,

cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",

qop=auth,

response="8ca523f5e9506fed4657c9700eebdbec", //用户名，密码等计算出来的摘要

opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

细节请参考rfc7616。

现在基本也没有Web应用采用HTTP Digest认证，但还可以把它用于内部API调用的认证。

HTTP Form认证

我们平时在登陆各大互联网站时所看到的登陆页面基本都是基于Form认证，业界没有关于Form认证的标准，但大家的实现却大同小异，基本的流程是：

用户在登录页面输入用户名/密钥并点击提交按钮。这里密钥可以是密码、一次性Token(OTP)、指纹、虹膜、面部特征等，甚至可能是多种密钥结合（multifactor authentication）
浏览器把用户名和密钥发送给服务器，HTTP请求的Body一般是Form类型的，也可以使用其他类型如JSON。所以其实叫Form认证并不确切。
服务器验证用户名密码

这种方式跟HTTP Basic一样是明文传输的密钥，所以最好用HTTPS来传输。HTTP Form认证如今仍然Web应用最流行的身份验证方式。