单点登录SSO

一、概述

        工作中遇到，记录下来，以备后续查阅。

二、详解

模拟场景

        一门户网站，集成一第三方系统。

方案一

步骤1：第三方系统 给 门户网站 提供一个访问链接

步骤2：门户网站 给 第三方系统 提供一个专门解析token的接口，用于验证token的合法性，并返回身份信息

步骤3：门户网站 请求 第三方系统 提供的链接，并将token令牌传递给 第三方系统，第三方系统 收到token后，通过 门户网站 提供的验证接口验证token的合法性，并拿到身份信息

步骤4：第三方系统 拿到身份信息后，匹配用户，生成自己的会话标识（token）

步骤5：跳转到 第三方系统 的指定页面

方案二

步骤1：第三方系统 给 门户网站 提供一个访问链接

步骤2：门户网站 给 第三方系统 提供一个私钥，和SDK（用于令牌解析和身份验证）

步骤3：门户网站 请求 第三方系统 提供的链接，并将token令牌传递给 第三方系统，第三方系统 收到token后，通过 门户网站 提供的私钥和SDK自行解析令牌，验证令牌合法性，并获取身份信息

步骤4：第三方系统 拿到身份信息后，匹配用户，生成自己的会话标识（token）

步骤5：跳转到 第三方系统 的指定页面

小知识：什么是token令牌

        用于表示某种权限或身份的令牌。通常是一个加密的字符串。可以存放在请求头或请求体。

小知识：上述方案2中SDK的作用

        令牌解密和验证：使用私钥对令牌进行解密，并验证令牌，确保其完整和合法性。

        用户身份信息获取：通过解析令牌，SDK可以提供方法来获取用户的身份信息，例如用户名、角色或其他相关的用户属性。

三、Oauth2.0

如下已问答的形式了解知识点。

问：Oauth服务器由门户网站提供，还是被集成的系统提供

答：OAuth 服务器通常由提供服务的门户网站（也称为认证服务器或身份提供者）来提供，而不是被集成的系统提供。

在 OAuth 协议中，门户网站充当身份认证和授权控制的中心。被集成的系统（也称为客户端应用）需要与门户网站进行集成，并通过 OAuth 协议与其进行通信，以获取用户的授权访问令牌。

具体而言，集成系统作为 OAuth 的客户端应用，需要提供一些信息给门户网站，例如注册客户端应用并获得客户端ID和客户端密钥等凭证，然后将用户重定向到门户网站的认证页面，以便用户进行身份验证并授权客户端应用访问特定资源。一旦用户完成身份验证和授权，门户网站将向客户端应用颁发访问令牌，并将访问令牌发送给客户端应用，后者可以使用该令牌来访问受保护的资源服务器。

因此，OAuth 服务器通常由门户网站（身份提供者）提供，并由客户端应用与其进行集成，以实现用户的身份验证和授权控制。

问：集成系统需要提供哪些信息给门户网站

答：为了与门户网站进行OAuth集成，集成系统需要向门户网站提供以下信息：

1. 客户端ID（Client ID）：这是由门户网站生成的唯一标识符，用于识别集成系统作为OAuth客户端应用。

2. 客户端密钥（Client Secret）：这是由门户网站生成的秘密密钥，用于与门户网站进行安全通信，验证客户端应用的身份。

3. 回调URL（Redirect URI）：集成系统需要提供一个回调URL，在用户完成身份验证和授权后，门户网站将用户重定向到该URL，同时传递授权访问令牌。

这些信息通常在集成系统注册为OAuth客户端应用时提供给门户网站。具体的注册过程可能因门户网站的实现和OAuth版本的不同而有所差异。在注册时，通常还需要提供一些其他的元数据和配置信息，以确保正确的集成和身份验证流程。

集成系统需要确保安全地保管客户端ID和客户端密钥，以防止它们被未授权的第三方获取。这些信息是与门户网站的身份验证和授权过程相关的重要凭证，应该得到妥善保护和管理。

问：客户端id和密钥是先由门户网站生成，然后配到集成系统里面吗

答：是的，通常情况下，客户端ID和密钥是由门户网站（或认证服务器）生成，并通过一种安全的方式提供给集成系统。

集成系统在与门户网站进行OAuth集成之前，需要先在门户网站注册客户端应用。在注册过程中，门户网站会生成一个唯一的客户端ID，并为客户端应用生成一个相应的客户端密钥。

门户网站会将生成的客户端ID和客户端密钥提供给集成系统。通常，这些信息会以安全的方式进行传递，例如通过安全加密的通信渠道或通过安全的文件传输方式。

集成系统接收到客户端ID和客户端密钥后，会将其配置到自己的应用程序中，以便在与门户网站进行OAuth交互时进行身份验证和授权。

需要注意的是，为了确保安全性，集成系统应该妥善保管客户端ID和客户端密钥，避免将其泄露给未经授权的第三方。

总之，客户端ID和密钥首先由门户网站生成，然后提供给集成系统，以实现OAuth集成。

问：集成系统里面需要配置门户网站提供的oauth服务地址吗

答：是的，集成系统在与门户网站进行OAuth集成时，通常需要配置门户网站提供的OAuth服务地址。

OAuth服务地址是指门户网站的认证服务器端点，用于完成认证和授权流程。集成系统需要知道这个地址，以便在需要与门户网站进行身份验证和授权交互时，能够正确地发送请求到门户网站。

在集成系统的配置中，通常会有一个字段或参数用于指定门户网站的OAuth服务地址，集成系统需要将该地址配置为正确的门户网站提供的服务地址。

这个OAuth服务地址通常是由门户网站提供给集成系统的，可以是一个URL地址，例如：https://oauth.example.com/authorize。集成系统需要使用这个地址来构建OAuth请求、处理回调和向门户网站发送授权请求等。

确保集成系统正确配置门户网站提供的OAuth服务地址是完成OAuth集成的重要步骤，并且是与门户网站建立安全通信和顺利完成认证授权流程的关键之一。

问：调用oauth服务器，请求头的用户代理值有什么用

答：在使用OAuth协议进行身份验证和授权过程中，请求头中的用户代理（User-Agent）值有以下作用：

1. 标识客户端应用：用户代理值可以提供有关发起请求的客户端应用的信息。这可以帮助服务器识别请求的来源，并作为对客户端应用的验证之一。

2. 支持统计和分析：通过收集和分析请求头中的用户代理值，服务提供商可以了解有关客户端应用的信息，例如不同设备、操作系统或应用版本的分布情况。这可以帮助服务提供商做出相应的优化和改进。

3. 安全性考虑：某些安全机制可能使用用户代理值来检测和防止恶意请求。例如，服务提供商可以根据用户代理值来识别和阻止来自特定类型的客户端应用或设备的请求。

要注意的是，用户代理值可以由客户端应用自行设置，并不是强制要求的字段。在实际应用中，可以根据具体需求和安全考虑，决定是否在请求头中包含用户代理值，并对其进行相应的处理和验证。

总而言之，请求头中的用户代理值在OAuth协议中用于标识和识别发起请求的客户端应用，并在某些情况下进行统计、分析和安全验证。

问：客户端自行设置后，oauth服务端需要特殊配置吗

答：OAuth服务端一般不需要进行特殊配置来处理客户端自行设置的用户代理值。

在OAuth协议中，OAuth服务端通常关注的是处理身份验证和授权请求，并验证客户端应用的身份和权限。对于请求头中的用户代理值，OAuth服务端通常不需要对其进行特殊处理，也不需要配置额外的规则。

然而，OAuth服务端在验证客户端应用的身份时，可能会使用其他方式来确保客户端应用的真实性和安全性，而不仅仅依赖于用户代理值。例如，在注册客户端应用时，Auth服务端可能要求客户端应用提供其他证书或凭据。

需要注意的是，如果OAuth服务端对于用户代理值有特定的要求或规定，那么客户端应用在设置用户代理值时应该遵守这些要求。例如，一些OAuth服务端可能要求用户代理值必须是特定格式或包含特定信息，这时客户端应用需要相应地设置用户代理值。

综上所述，一般情况下，OAuth服务端不需要特殊配置来处理客户端自行设置的用户代理值。OAuth服务端主要关注验证身份和授权流程，而用户代理值通常在客户端应用控制和配置。

问：oauth验证方式

答：OAuth协议提供了几种不同的验证方式，主要包括以下四种：

1. 授权码模式（Authorization Code Grant）：这是最常用的OAuth验证方式。客户端应用将用户重定向到认证服务器，用户在认证服务器上登录并授权后，认证服务器将生成一个授权码，并将其发送回客户端应用。客户端应用使用授权码向认证服务器请求访问令牌（Access Token）。

2. 简化模式（Implicit Grant）：简化模式适用于无法安全保存客户端密钥的原生应用或浏览器基础的应用。客户端应用将用户重定向到认证服务器，并在重定向URL的锚点参数中接收访问令牌，以实现直接授权，而不需要通过授权码的中间步骤。

3. 密码模式（Resource Owner Password Credentials Grant）：密码模式允许客户端应用使用用户的用户名和密码直接向认证服务器请求访问令牌。这种方式通常用于受信任的应用程序，比如原生移动应用或托管在安全环境中的应用。

4. 客户端凭证模式（Client Credentials Grant）：客户端凭证模式用于客户端应用自身以客户端身份向认证服务器请求访问令牌，而不是代表用户。这种验证方式适用于无需用户参与的机器到机器通信，例如客户端应用需要访问受保护的API资源。

每种验证方式在不同的场景下具有不同的适用性和安全性要求。选择合适的验证方式取决于你的应用类型、安全需求和使用场景。通常建议使用授权码模式，因为它是最安全和最常见的OAuth验证方式之一。

问：Bearer授权类型

答：Bearer 授权类型是 OAuth 2.0 中定义的一种常见的授权类型。它允许客户端应用以简单的方式向资源服务器（Resource Server）请求访问受保护的资源。

使用 Bearer 授权类型时，客户端应用在请求中使用访问令牌（Access Token）作为身份验证凭证。请求头中的 Authorization 字段中通常包含 “Bearer” 关键字，后跟空格和访问令牌。例如：

Authorization: Bearer <access_token>

Bearer 授权类型的特点包括：

1. 简单性：使用 Bearer 授权类型时，客户端应用只需在请求头中附加访问令牌即可，无需包含复杂的参数或签名。

2. 无状态：Bearer 授权类型是无状态的，即授权服务器（Authorization Server）不需要在服务器端维护关于令牌的状态。每个请求都需要提供有效的访问令牌，服务器仅使用令牌本身进行身份验证。

3. 有限的安全性：Bearer 授权类型中的访问令牌通常是一个字符串，没有额外的结构或加密。这意味着在传输过程中，令牌可能会受到窃听和伪造的风险。因此，使用 HTTPS 进行通信是非常重要的，以确保令牌的安全性。

需要注意的是，Bearer 授权类型是一种简化和常见的授权方式，适用于一些简单的应用场景。对于更高级的安全需求或对访问令牌更多控制的需求，可以采用其他授权类型，如基于签名的授权方式。使用授权类型时，要根据实际情况选择合适的授权类型，并确保相应的安全措施得到实施。

其他参考资料：

oauth2.0授权码模式详解_oauth2.0 授权码_[虚幻私塾】的博客-CSDN博客