不同生态下的认证授权体系
工作日常中的软件开发人员，往往会根据项目情况来学习认证与授权（以下或统称为Auth）的基础概念、了解某一项协议流程、应用某些凭证或集成身份系统，然后就可以万事大吉了。因为大多数情况下，业务功能才是核心开发工作，认证授权机制一旦建立，软件运行规模暂时稳定，需要市场逐步反应和发展，所以在几年内，认证授权体系就很少有变动的机会了。
也是因为以上原因，我们鲜少形成对认证授权领域的全面性了解，也缺乏对其设计及演进的能力。本篇文章可视为对auth体系“纸上谈兵”的畅想，开启对认证授权体系在不同软件生态环境下的设计之路。
一.不同的软件系统生态
现在，在结合具体的Auth知识之前，让我们先来定义一下不同的软件系统生态，目的是为了具有一致的场景了解，然后再涉及Auth内容时，需求和复杂性才更易理解。不过需要澄清的2点是：
- 生态定义当然应该由简单到复杂，任何新知识都应该从简单开始学起，最终在复杂情况下应用。没有人可以一口吞下一头大象。
- 简单还是复杂，我们是站在设计认证授权机制的角度上来定义的。统一视觉角度很重要。
基于以上2点，作者本人将软件生态分为三种，分别是无生态软件系统，发展中软件生态和复杂软件生态。并分别给出定义、原因和示例。
无生态软件系统
定义：仅支持终端用户的单个SAAS、或较少服务的SAAS体系
原因：重心在于对用户的认证及业务数据的权限保护，业务领域较为单一，系统组成简单。软件内部交互受安全边界保护，可适当简单设计。
举例：需要用户登录的某个网站。
发展中软件生态
定义：终端用户+Open API 的SAAS体系；或众多业务系统组成的SAAS体系
原因：不仅要考虑用户的认证授权，还因为开放了API，不仅有内部软件的交互，还要考虑对外部软件调用的认证与授权。而多业务系统组成的SAAS体系，则需要考虑更便利而安全的用户登录体验。
举例：开放Restful API的GitHub；Google workspace。
复杂软件生态
定义：终端用户+Open API的SAAS及PAAS/IAAS的混合体系
原因：此时不仅有含有不同的认证主体，用户或者外部软件；还有较为复杂的认证主体模拟、认证主体在不同环境下（互联网、本地开发环境、生产运行环境）的认证授权机制、详尽的权限机制设计和流程等问题。
举例：Google workspace + cloud 生态。
二.认证授权概念梳理
在认证授权领域，存在着大量概念和词汇。针对某个单独的事项，我们可以较为轻松的使用，但如果讲所有这些概念放在一起，我们还能够正确区分与联系它们吗？在本块内容中，我们按认证和鉴权2个阶段将其梳理与归类，总结如下
认证阶段
身份主体与凭证：
- 用户账号：用户名与密码；邮箱与密码；手机号与验证码 等
- 服务账号：OAuth Client id & secret；API key（标识API调用方）；AWS access key & secret 等
临时电子凭证：ID token；
身份系统概念：IdP，AD，LDAP （均为提供和管理账号信息的系统或服务）
身份认证模式/解决方案：SSO（单点登录，一次登录，可访问多个系统）
认证标准及流程控制协议：HTTP auth；OpenID；SAML；CAS
身份系统概念中，IdP（身份提供方）是更宏观抽象的统称概念，它的具体和底层实现可以是AD服务、LDAP系统或者其他。认证标准和协议往往规定了完成整个认证过程的流程及指定的通信方角色及交换的信息等。虽然不同协议的细节有所差异，但是通常流程是，资源所有者访问资源，资源提供方判断其未登录后跳转到 IdP 或自身登录页面以获取身份凭证并验证, 完成验证后 IdP告知资源提供方以初步放行。下图仅对通用流程示意，忽略实现细节的准确度。
授权阶段
临时电子凭证：access token
权限控制: ACL，RBAC，ABRC，OAuth scope
标准及流程控制协议：OAuth 2
通常来讲，在授权阶段会分为几个小步，完成身份认证后，授权服务器（即 IdP）会颁发一个临时的、指定了特定权限的token，之后资源访问方带着该token发出请求时，授权服务器（或资源服务器）会进行鉴权，以确认临时token有效，并根据已设置的具体权限策略放行或者拒绝。
三.如何随生态发展演进Auth体系
随着业务的发展，商务规模的扩大将映射在软件系统的演进上。作为架构师，如果能正确掌握auth体系在不同软件生态下的演进思路，则会更省时有效地促成客户业务发展。以下内容则是auth功能在不同生态下的设计演进详情。
无生态软件系统：此时软件系统往往内建简单的auth模块或服务。可从支持最基础的身份凭证开始，如可以只做邮件的用户认证，及简单的服务器间（应用间）认证，授权方面关注于业务数据的用户权限隔离。此时auth体系的拓展点如，支持更多身份凭证，如手机号及验证码、其他social media IdP（微信，Google），为了增强安全性可考虑支持多步联和验证。
发展中软件生态：此时，客户业务覆盖多个领域，并且领域系统间会有业务渗透和推广，为了提供用户认证便利性并增强体验，应考虑将自身auth服务或模块发展为独立的、功能健全的IdP系统，并在不同业务系统中全面应用SSO模式；而当客户决定开放系统 API 以增强软件服务在整个互联网环境下的影响力时，就是考虑应用OAuth 2流程来提供资源给第三方系统的时候了，此时丰富的API能力也需要较为细致的API资源及权限划分，以应用最小权限原则减少权限风险。
复杂软件生态：基于发展中软件生态的auth体系之上，可将IdP系统完善至SaaS服务，即IDaaS。并考虑对外部IdP联和提供支持；提供auth sdk及命令行工具进行环境识别和查找用户信息；拟定涵盖云资源的详尽权限规则，提供便利的权限配置管理服务。以下列出三个具体场景举例描述
身份模拟（委托）
身份模拟和委托可以临时获取到另一个身份的权限，而不用变更自身的配置。这在复杂软件生态中拥有应用场景:
- 两个身份分别处于不同软件账号（项目），此时有跨软件账号资源访问需求，可通过临时委托达到访问目的。
- 个人账号模拟服务账号，部分资源当前只支持服务账号进行访问以进行自动化管理，此时不具备权限的个人账号可进行临时模拟，以临时提升账号权限。
软件生态中的auth工具
复杂软件生态下，不仅存在用户账号，也存在服务账号，并且这些服务账号不仅应用于开发者本地，还会绑定到软件生态自己的资源上。那么面对这些不同的情况，往往需要软件生态提供对应的Auth库或者Cli tool来自动化识别不同环境下的身份。这一识别过程中，识别顺序和优先级往往不能少，好处则在于一处开发多处使用。
权限管理配置
复杂软件生态下资源类型和操作纷繁复杂，往往需要结合应用不同的权限管理策略，如ACL，ABAC，RBAC。并且能为用户提供灵活的配置途径及一些内置可选权限设置成为必不可少的需求。UI 和 API 的权限配置、查询成为软件生态里不可缺少的基本能力。
本文的目的在于立足认证授权的角度，按设计和需求的复杂度将不同的软件生态环境进行分类，然后将繁杂的认证授权概念进行简单梳理，最后将其联系归纳为不同软件生态下的auth体系设计思路。这样，即使对每种技术的细节不清晰，我们也大概的了解了Auth功能到底应该怎么设计和规划，向“胸有成竹”这个目的地迈出第一步。