微服务系统之认证管理（普元IAM）

转自：http://www.primeton.com/read.php?id=2667&his=1

引言：

微服务大行其道，微服务安全也是非常热门的话题。本文向大家分享微服务系统中认证管理相关技术。其中包括用户认证、网关和 API 认证、系统间和系统内的认证，以及我们的统一认证管理系统 IAM。

目录：
一、简介
二、用户认证
三、网关及API调用认证
四、系统间认证和系统内认证
五、总结

一、简介

首先，我们来看一下什么是认证？

认证是确认当前声称为 xxx 的用户确实为 xxx 本身。

用户可以是人、系统、应用或任意调用者。

最简单的认证，就是用户名密码登录，常见的认证方式还有：手机验证码、生物识别（指纹，虹膜识别、面部识别等）、U 盾、数字证书。

关于认证更加详尽的定义和认证方式，请参见维基百科：https://en.wikipedia.org/wiki/Authentication

那在微服务系统中有哪些地方需要进行认证管理(不包括DevOps中的认证)呢？如下图所示：

凡是存在交互的地方均需要进行认证：

用户访问系统

系统调用网关

网关调用系统

系统内应用之间的调用

系统间的调用

可以将它们分为如下三类：

用户认证

系统间及系统内认证

网关及 API 调用认证

下面我们将对这三类认证，分别做详细的介绍。

二、用户认证

微服务架构中会存在很多系统，而且系统间的切换也需要无缝进行，例如一个前端框架中可能会集成多个系统的调用。此时，我们自然而然的会想到单点登录，单点登录早在已存在。但微服务中的单点登录与传统的单点登录有一定的差异。

下面这幅图描述传统的基于 Session 的单点登录。

用户的授权信息（例如角色，可访问资源等）保存在应用的 session 中，浏览器与应用系统之间基于sessionID 关联，相同应用的集群使用缓存（如 Redis、memcached 等），或基于 session 复制来进行共享 session 信息。

但是微服务系统中，api 的调用都是 stateless，没有状态信息，如下图所示：

用户的授权信息通常直接封装到 token 中，用户在访问应用或系统的时候，携带上 token，应用或系统直接从 token 中反解出用户的授权相关信息

2.1.OAuth2.0与SSO

OAuth2.0是授权框架，SSO 是认证服务，但是我们可以基于 OAuth2.0实现SSO 认证服务。

OAuth2.0本身不提供认证服务，但是具有足够的扩展空间，让我们来扩展，例如基于 OAuth2.0 的OIDC。

2.2.基于OAuth2.0的单点登录

上图所示,为一个基于OAuth2.0的 SSO的流程，整体流程基本上和普通的 SSO 一致，所不同的是，存储 app Cookie 的时候，保存的是经过应用或系统处理和加密过的 token，用户后续请求，带上加密后的 token，在 app 后端直接解密和抽取出用户相关的授权信息，流程如下:

1. 用户访问app1.com
2. 由于用户没有登录，因此跳转到 iam.com
3. 用户在 iam.com的登录页面，输入用户名和密码，确认提交，iam 校验成功后
4. 在浏览器端写入浏览器cookie
5. 重定向到 app1.com，并获取 token(此处获取 token流程，与OAuth2.0协议有关)
6.app1.com检查 token 有效性
7. 重定向用户访问页面，并存储 app1.com的token 到app1.com的cookie 中
8. 用户访问app2.com
9.app2.com重定向到iam.com
10.iam.com此时发现 cookie 内已经有认证的token（或 session）信息
11. 直接重定向到app2.com,并获得 token 信息
12.app2.com验证 token 信息
13. 重定向到app2.com,并保存app2.com的 token 信息到 app2.com 的 cookie 中

2.3.Token

通常情况下，IAM会使用类似jwt 这样的协议去封装用户信息和授权相关信息。

App需要对 Token 进行处理，加密后再存入到浏览器 cookie 中去。