一、基础概念：IAM、认证与授权
IAM（身份与访问管理） 身份和访问管理（Identity and Access Management, IAM）是一个广泛的安全框架，其核心目标是确保在企业组织中，正确的实体（用户、设备或服务）能够访问相应的资源。
本质上，IAM关注两个核心问题：
- 身份（Identity）： 一个用户、服务或设备的数字表示。身份通常包含名称、电子邮件、角色等一系列属性，用以描述这个实体是谁。
- 访问（Access）： 与某个资源进行互动、执行某个操作或使用某项服务的能力。访问定义了“谁”可以在“哪些资源”上执行“哪些操作”。
认证（Authentication） vs. 授权（Authorization） 这两个词在IAM的讨论中经常同时出现，但含义截然不同，区分它们至关重要。
- 认证（Authentication）： 是验证一个身份所有权的过程。它回答的问题是：“你是谁？”或者“你如何证明你就是你所声称的那个人？”
- 授权（Authorization）： 是确定一个已经通过认证的身份，可以对某个资源执行哪些操作的过程。它回答的问题是：“你能做什么？”
授权是访问控制（Access Control）的一个子集。访问控制是一个更广泛的概念，除了授权，还可能包含其他限制策略。
举个例子：一个用户（身份）想要在一个API（资源）上执行GET请求（操作）。 在执行任何操作之前，该用户必须先通过输入密码、指纹验证等方式完成认证过程，证明自己的身份。 认证通过后，系统需要判断该用户是否有权限在那个API上执行GET请求，这个过程就是授权。
二、OAuth 2.0：安全的“授权委托书”
OAuth 2.0（通常简称为OAuth）是一个授权框架。它允许一个应用程序（客户端）在用户的授权下，去访问另一个应用程序（资源服务器）上受保护的资源。
例如，假设你有一个名为MyApp的Web应用，它想要访问你存储在Google Drive里的文件。MyApp不应该向你索要Google Drive的账号和密码。正确的做法是，MyApp使用OAuth 2.0协议，请求Google的许可（授权），以代表你的名义去访问你的Drive文件。
在这个流程中，MyApp是请求访问Google Drive（资源）的客户端。用户（资源所有者）在过程中会明确地授予MyApp访问权限。OAuth 2.0流程的一个关键产物是访问令牌（Access Token），客户端会使用这个令牌来向资源服务器证明，它已经获得了用户的授权。
需要注意的是，OAuth 2.0本身并没有定义用户是如何向Google验证自己身份的，它只关心“授权”这一环。
三、OIDC：“授权”之上的“认证”层
OpenID Connect (OIDC) 是一个构建在OAuth 2.0之上的认证层。它在OAuth 2.0的基础上，专门添加了用于身份认证的功能，例如ID令牌（ID Token）和UserInfo端点。这使得OIDC既能处理授权，又能完美地处理认证。
我们换个例子。如果MyApp的目标不是访问你的Google Drive，而是希望允许你“使用Google账户登录”，那么它的核心诉求就从“访问资源”转向了“验证身份”。在这种情况下，OIDC就比纯粹的OAuth 2.0更适合。
OIDC流程与OAuth流程非常相似，但关键区别在于：除了可能有的访问令牌，OIDC还会提供一个ID令牌。这个ID令牌是一个JWT（稍后会解释），其中包含了已认证用户的基本信息（如用户ID、姓名、邮箱等）。MyApp在收到这个ID令牌后，就可以验证用户的身份，而无需再向Google发出额外的请求。
四、SAML：企业级的“老将”
安全断言标记语言（Security Assertion Markup Language, SAML）是一个基于XML的、用于在不同系统之间交换认证和授权数据的框架。SAML诞生于21世纪初，被广泛应用于企业级的IT环境中，尤其是在单点登录（SSO）场景下。
SAML在功能上与OIDC相似，但在实现细节上有所不同：
- SAML： 使用基于XML的断言（Assertion）来传递信息，通常被认为配置和实现起来更复杂。
- OIDC： 利用JSON和JWT（JSON Web Token）来传递信息，使其更轻量、更易于现代Web和移动应用的开发。
现代应用程序通常因其简单性和灵活性而偏爱使用OIDC，但SAML在许多现有的企业系统和遗留用例中仍然非常普遍。
五、单点登录(SSO)：一次登录，畅行无阻
单点登录（Single Sign-On, SSO）是一种认证方案或用户体验。它允许用户使用一套凭据（例如，一套用户名和密码）来访问多个不同的应用程序和服务。用户无需在每个应用上单独登录，只需在第一次访问时登录一次，之后便可无缝访问所有已连接的受信任系统。
SSO依赖于一个中心的**身份提供者（Identity Provider, IdP）**来统一管理用户身份和认证过程。IdP负责验证用户身份，并为所有连接的应用程序提供认证和授权服务。
这个IdP可以使用OIDC、SAML或其他协议来提供这些服务。一个强大的IdP通常可以支持多种协议，以满足企业内不同应用程序的多样化需求。
六、JWT：紧凑自包含的“数字身份证”
JSON Web Token (JWT)，通常读作“jot”，是一个在RFC 7519中定义的开放标准，用于在两方之间安全地传递信息。它是OIDC中ID令牌的标准格式，也广泛用于OAuth 2.0的访问令牌。
JWT的关键特性：
- 紧凑： JWT本质上是一个经过编码的JSON对象，格式紧凑，便于在网络中传输和存储。
- 自包含： JWT内部包含了关于用户和令牌本身的所有必要信息（如用户ID、过期时间等）。
- 可验证和可加密： JWT可以被数字签名以确保数据的完整性（未被篡改），也可以被加密以确保保密性。
一个典型的JWT看起来像这样： eyJh0dbd3cf390a36IkpXVCJ9.eyJzdWIiOiJmb28iLCJuYW1lIjoiSm9obiBEb2UifQ.XM-XSs2Lmp76IcTQ7tVdFcZzN4W_WcoKMNANp925Q9g
它由三个部分组成，用点（.）隔开：{{header}}.{{payload}}.{{signature}}
- Header（头部）： 包含令牌的元数据，如令牌类型和签名算法。
- Payload（负载）： 包含声明（claims），即关于实体（通常是用户）和令牌本身的附加信息。
- Signature（签名）： 用于验证令牌的完整性。
头部和负载都是经过Base64编码的JSON对象。使用JWT，客户端应用在收到令牌后，可以自行解码并提取其中的用户信息，而无需再向身份提供者发出额外的请求来获取，从而提高了效率。
七、赛锐信息观点
我们已经了解了很多概念，现在用一个例子来把它们串联起来：假设你有一个Web应用AppA，需要一个IAM解决方案。你选择了Logto（一个身份服务提供商）作为你的IdP。
- Logto使用OIDC协议来进行用户认证。由于OIDC建立在OAuth 2.0之上，Logto也自然支持授权功能。
- 为了提升用户体验，你在Logto中启用了“使用Google登录”功能。这个过程利用了OAuth 2.0，在Logto和Google之间交换授权数据和用户信息。
- 当一个用户通过Logto成功登录你的AppA后，AppA会收到一个ID令牌。这个令牌是一个JWT，其中包含了该用户的身份信息。
- 随着业务发展，你推出了一个新的应用AppB，它也需要用户认证。由于IdP（Logto）已经设置好，你可以为AppB复用相同的认证流程。你的用户现在可以使用同一套凭据登录AppA和AppB，这就实现了单点登录（SSO）。
- 后来，一个大型企业合作伙伴请求你，希望他们的员工能使用他们公司自己的企业级SSO系统来登录你的应用。他们的系统使用的是SAML协议。你发现Logto支持SAML连接，于是你设置了Logto与该合作伙伴的SAML系统之间的联合。现在，这个合作伙伴组织的用户也可以使用他们现有的企业凭据，无缝地登录你的AppA和AppB了。
通过这个例子，我们可以看到IAM、OAuth、OIDC、SAML、SSO和JWT这些概念是如何在现代企业应用中协同工作，共同构建起一个安全、便捷、可扩展的身份与访问管理体系的。
企业在向SAP S/4HANA Cloud转型时，SAP 许可 (License) 从 On-Premise 时代的经典指定用户模型转向全新的 FUE 许可模式，且 SAP 产品的许可 (License) 包含诸如“组件授权、用户授权、计量模式”等复杂模型，这对企业来说如同一个黑匣子，难以理解其工作原理。此外，企业还面临 SAP 的 License 审计等合规性问题。赛锐信息在 SAP License 审计流程方面拥有丰富咨询经验，拥有自主研发的高效 SAP License 资产优化软件产品，欢迎企业在需要时随时联系我们，以获得我们的支持服务和软件产品试用体验。
