MASA Auth - SSO 与 Identity 设计

作者：MASA技术团队

2022 年 5 月 27 日
本文字数：3173 字
阅读完需：约 10 分钟

AAAA

AAAA 即认证、授权、审计、账号（Authentication、Authorization、Audit、Account）。在安全领域我们绕不开的两个问题：

授权过程可靠：让第三方程序能够访问所需资源又不泄露用户数据，常用的多方授权协议主要有 OAuth2 和 SAML 2.0
授权结果可控：授权结果用于功能或资源的访问控制。常见的权限控制模型：DAC、MAC、RBAC、ABAC
想了解权限控制模型的话可以参照上一篇的权限设计

OpenId（Authentication）

OpenID 是一个以用户为中心的数字身份识别框架，它具有开放、分散性。OpenID 的创建基于这样一个概念：我们可以通过 URI （又叫 URL 或网站地址）来认证一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证

对于支持 OpenID 的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为 OpenID 身份提供者（Identity Provider, IDP）的网站上注册。

OAuth2（Authorization）

举个例子：MASA.Contrib使用codecov来分析单元测试覆盖率，OAuth2 帮我解决了几个安全问题：

密码泄露：不需要把账号密码告诉codecov
访问范围：只开放读取源码的能力
权限回收：在 Github 上撤回授权即可关闭codecov的访问能力

那 OAuth2 是如何解决的呢

我们来看一张图

OIDC（Authentication & Authorization）

OpenID Connect 1.0 是 OAuth 2.0 协议之上的一个简单的身份层。它允许客户端基于授权服务器执行的身份验证来验证终端用户的身份，并以一种可互操作的、类似 rest 的方式获取关于终端用户的基本概要信息。

OIDC 常用术语

EU：End User：终端用户
RP：Relying Party，用来代指 OAuth2 中的受信任的客户端，身份认证和授权信息的消费方
OP：OpenID Provider，有能力提供 EU 认证的服务（比如 OAuth2 中的授权服务），用来为 RP 提供 EU 的身份认证信息
ID Token：JWT 格式的数据，包含 EU 身份认证的信息
UserInfo Endpoint：用户信息接口（受 OAuth2 保护），当 RP 使用 Access Token 访问时，返回授权用户的信息，此接口必须使用 HTTPS

OIDC 工作流

RP 发送一个认证请求给 OP
OP 对 EU 进行身份认证，然后提供授权
OP 把 ID Token 和 Access Token（需要的话）返回给 RP
RP 使用 Access Token 发送一个请求 UserInfo EndPoint
UserInfo EndPoint 返回 EU 的 Claims

JWT

JWT（JSON Web token）是一个开放的、行业标准的 RFC 7519 方法，用于在双方之间安全地表示声明。

JWT 由 3 部分组成：标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候，会将 JWT 的 3 部分分别进行 Base64 编码后用.进行连接形成最终传输的字符串

JWT=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)

Header

JWT 头是一个描述 JWT 元数据的 JSON 对象，alg 属性表示签名使用的算法，默认为 HMAC SHA256（写为 HS256）；typ 属性表示令牌的类型，JWT 令牌统一写为 JWT。最后，使用 Base64 URL 算法将上述 JSON 对象转换为字符串保存

{  "alg": "HS256",  "typ": "JWT"}

复制代码

Payload

有效载荷部分，是 JWT 的主体内容部分，也是一个 JSON 对象，包含需要传递的数据（允许自定义）。

{  "sub": "1234567890",  "name": "John Doe",  "iat": 1516239022}

复制代码

Signature

签名哈希部分是对上面两部分数据签名，需要使用 base64 编码后的 header 和 payload 数据，通过指定的算法生成哈希，以确保数据不会被篡改

HMACSHA256(  base64UrlEncode(header) + "." +  base64UrlEncode(payload),  your-256-bit-secret)

复制代码

Identity Server 4 常用术语

Client：一个从 IdentityServer 请求令牌的软件——用于验证用户（请求身份令牌）或访问资源（请求访问令牌）。客户端必须先向 IdentityServer 注册，然后才能请求令牌
Allowed Scopes：即可以是 Identity Resource，也可以是 Api Scopes 和 Api Resources
Resource：您希望使用 IdentityServer 保护的东西，如用户的身份数据或 API。资源名称唯一
API Scope：API 作用域
可以当做是 Permission 来用，示例见：https://docs.duendesoftware.com/identityserver/v6/fundamentals/resources/api_scopes/
Identity Resource：关于用户的身份信息（又名声明），例如姓名或电子邮件地址
User Claims：身份声明，例如 sub，name，amr，auth_time 等
Identity Properties：身份资源本身的一些属性，例如 session_id，issued，expired 等
Identity Grants：被授予的身份信息
API Resource：一组 API Scope
User Claims：需要包含在 Access Token 中的用户声明列表
API Resource Scope：API 资源包含的作用域
API Properties：API 本身的一些属性，例如 name, display name, description 等
API Grants：被授权的 API 列表
Identity Token：身份令牌代表身份验证过程的结果。它至少包含用户的标识符以及有关用户如何以及何时进行身份验证的信息。它可以包含额外的身份数据
Access Token：访问令牌允许访问 API 资源。客户端请求访问令牌并将其转发到 API。访问令牌包含有关客户端和用户（如果存在）的信息。 API 使用该信息来授权访问其数据
Grant Types：授权类型（其实还有 Resource owner password，不推荐使用，就不过多介绍了）
参考自：https://docs.duendesoftware.com/identityserver/v6/overview/terminology/
Machine/Robot：Client Credentials
Web Applications：Authorization Code With PKCE（Proof Key for Code Exchange）
通常我们会选择id_token token作为 response type
还有一个选择，就是 Implicit。但在隐式流程中，所有令牌都通过浏览器传输，因此不允许刷新令牌等高级功能。作用范围就是仅用于用户身份验证（服务器端和 JavaScript 应用程序），或身份验证和访问令牌请求（JavaScript 应用程序）
SPA：Authorization Code With PKCE
Native/Mobile Apps：Authorization Code With PKCE
TV/Limited Input Device：Device Flow RFC 8628

ASP.Net Core Identity 常用术语

User：用户
Action：操作，包括增删改查
User Role：用户角色
User Claim：用户声明
Role：角色
Action：操作，包括增删改查
Role Claim：角色声明
Claim：声明是一个名称值对，表示使用者是什么，而不是使用者可以做什么。基于声明的授权检查声明的值并允许基于该值的资源访问
Policy：策略
Require Role：要求角色
Require Claim：要求声明
Require Assertion：更复杂的可以通过要求断言来解决，它支持两个重载的 Func（实际是一个，因为有一个是 Task）
Requirements：基于IAuthorizationRequirement接口定义一个要求，判断要求要基于AuthorizationHandler<T>来实现对应的逻辑
默认策略
回退策略
自定义授权属性
Resource：资源
Imperative：官方翻译是命令式，可以对特定的资源进行授权策略处理

依赖模型

集成 RBAC

通过.Net Core Identity 的 User Claimns 将 User Role 与 Api Resource、Api Scope、Identity Resource 相关联，可以在不同业务维度下获取到用户的角色

再配合 ASP.Net Core Identity 的 Role 或 Policy 进行资源授权判断来达到 SSO 与 RBAC 的业务落地

总结

本章节涉及到 OIDC、ASP.Net Core Identity 和 RBAC 三部分内容。首先 OIDC 的知识体系就比较庞大，需要根据比较完善的文档把概念都搞清楚以及为什么这么设计的原因，其次还要进行一些微调把 OIDC、RBAC 与 ASP.Net Core Identity 三者结合。可以看出依赖模型其实是个很粗的把各个环节串了起来，但实际落地过程中还免不了对依赖模型进行二次调整来满足不同业务的需求。后续等 MASA Auth 落地后会再出第三篇文章来回顾和还原实际落地过程。

（本文章不代表最终设计）