1、身份认证与授权体系设计

SaaS架构：身份认证与授权体系设计

原文：https://mp.weixin.qq.com/s/WaHwOKax5TyMm9H29_uR0Q

SaaS 产品要安全地服务海量客户，它的身份认证与授权体系设计就显得非常重要，不单是安全的第一道防线，更决定了用户体验、系统扩展性与运维成本。

今天，极特就继续跟大家分享下，SaaS架构中身份认证与授权的设计原则、主流模型与技术实践。

认证与授权

在深入之前，我们先来了解下两个基本概念：认证和授权。

• 认证，是关于你是谁的问题。系统需要验证访问者的身份，确认其是合法用户。常见的认证方式包括用户名密码、手机验证码、指纹或面部识别等。
• 授权，则是关于你能做什么的问题。在确认用户身份后，系统需要根据其角色和权限，决定他可以访问哪些资源、执行哪些操作。

简单来说，认证是确认你是谁，授权是定义你能做什么。在SaaS中，两者必须清晰分离，但又紧密协作。

多租户挑战

SaaS跟单体应用最大的不同，就是天生要支持多租户。说白了，系统必须清楚地知道每个租户的身份、数据和权限边界在哪。

一个用户可能同时是好几家公司的员工，在A公司是管理员，在B公司可能只是普通员工。

这就要求我们的设计必须足够灵活，并且隔离要做到滴水不漏，绝对不能让A公司的张三看到B公司的财务报表。

统一认证 (SSO)

我们先来说说认证。现在哪个SaaS产品要是没个单点登录（SSO），都不好意思跟人打招呼，特别是对那些一天要切换好几个系统的B端用户来说，更是刚需。

用户只需登录一次，就可以在多个互相信任的应用系统之间无缝切换，无需反复输入账号密码。

SSO的核心是建立一个统一的身份提供商（Identity Provider, IdP）。所有业务应用（Service Provider, SP）都信任这个IdP颁发的身份凭证。

实现SSO，业界有几种成熟的标准化协议，其中最主流的就是OIDC和SAML。

OIDC

OpenID Connect (OIDC) 是目前构建SSO最主流的协议。它基于OAuth 2.0框架，但玩法上增加了一个身份层。

OIDC的玩法核心是ID Token，这是一个JWT（JSON Web Token）格式的令牌。当用户通过IdP成功认证后，IdP会颁发ID Token给客户端。

这个ID Token包含了用户的基本身份信息（如用户ID、姓名、邮箱等），并且带有IdP的数字签名，SP可以验签以确认其真实性。

SAML 2.0

在OIDC一统江湖之前，SAML 2.0是企业级SSO的老大哥。它基于XML，虽然看起来有点笨重，但在许多传统企业和联邦认证场景中仍被广泛使用。

对于需要与企业客户内部身份系统（如AD域）集成的SaaS产品，支持SAML是打入大客户内部的必要一环。

授权模型

解决了你是谁的问题，接下来是更复杂的你能做什么。

RBAC

基于角色的访问控制（Role-Based Access Control, RBAC），逻辑简单，将权限（Permission）赋予角色（Role），再将角色赋予用户（User）。这样，用户就通过角色间接拥有了操作权限。

在SaaS中，RBAC模型通常会演变为 User -> Tenant Role -> Permission。角色被限定在特定的租户空间内。

RBAC的局限

RBAC虽然简单直观，但处理复杂授权场景的时候，就会有点不怎么给力了。例如：

• 某个财务角色只能查看自己创建的报表。
• 某个区域经理只能管理华东大区的客户数据。

怎么理解呢，就像你给保安配钥匙，一开始只有两种钥匙，只有能进大门 和 能进所有房间。但后来需求变成只能进自己部门的门，你就得为每个部门都配一把新钥匙，钥匙串越来越大，就非常不好管理了。

ABAC

基于属性的访问控制（Attribute-Based Access Control, ABAC），核心思想是通过动态计算一系列属性来决定是否授权。属性多样，可以是：

• 用户属性：年龄、部门、职级等。
• 资源属性：创建者、所属项目、敏感等级等。
• 环境属性：访问时间、IP地址、设备类型等。

所有这些属性组合成一条条策略（Policy），构成一个强大的决策引擎。

举栗，允许财务部门的经理在工作日的9点到18点之间，访问本部门创建的、密级为 内部 的财务报表。这种复杂的规则用ABAC可以轻松实现。

技术实现

JWT

在现在的微服务天下，JWT（JSON Web Token）基本上是传递身份信息的圣旨。

当用户登录后，IdP会生成一个JWT。这个JWT包含了用户的唯一标识、所属租户ID、角色列表等关键信息，并使用密钥进行签名。

客户端在后续的每次API请求中，都会在HTTP头中携带这个JWT。API网关或后端服务只需验证JWT的签名，无需查询数据库，即可信任其中的信息，实现无状态鉴权。

一个典型的JWT Payload可能如下：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
{
  "sub": "user-123",
  "tenant_id": "tenant-abc",
  "roles": ["admin", "finance_manager"],
  "exp": 1678886400
}

API网关

在微服务架构中，API网关是实现认证授权的理想位置。

所有外部请求首先经过API网关。网关负责：

• 校验请求中JWT的合法性。
• 解析JWT，提取用户信息和租户信息。
• 执行粗粒度的授权检查（例如，检查用户是否有所需的角色）。
• 将解析后的用户和租户信息注入到请求头中，传递给下游的微服务。
• 下游微服务可以信任这些信息，专注于业务逻辑，或执行更精细的业务层授权。

写在最后

一个好的设计，需要在安全性、用户体验、灵活性和性能之间找到最佳平衡。

从OIDC和SSO提供的统一认证，到RBAC与ABAC结合的精细化授权，再到以JWT和API网关为核心的技术落地，构建一个强大而优雅的认证授权体系，是SaaS产品走向成功的基石。