单点登录与授权登录业务指南

JanYork_小简

发布于 2024-03-05 09:03:28

5590

发布于 2024-03-05 09:03:28

文章被收录于专栏：小简技术栈小简技术栈

前言

本文篇幅较长，旨在详细的让读者搞清楚单点登录与授权登录两套业务的详细流程与相关知识，如不喜欢长篇幅或者嫌弃啰嗦的请不要阅读。
本文代码部分由AI编写，不一定准确，但是肯定可以参考，逻辑正确。
本文部分内容从互联网进行了些许参考，并且素材声明了来源。
单点与授权的业务很简单，但是想要详细的掌握并完成需求也不是可以直接上手的。

何为单点？何为授权？

有什么地方不正确或者缺少了某些知识请及时告诉我，感谢。

单点登录

单点登录（SSO）是一种用户身份验证过程，允许用户使用单一的登录凭据来访问多个应用程序或服务。它减少了需要记忆多个用户名和密码的需求，提高了安全性和用户体验。SSO在企业环境中尤为重要，因为它简化了对多个内部和外部服务的访问过程。

使用Google账号登录各种服务。例如，你可以用Google账号登录Gmail，然后不需要再次登录就能访问Google Drive、Google Photos、YouTube等Google服务。这种方式让用户无需记住多个账号和密码，提供了便捷和高效的用户体验。

授权登录

授权登录，如OAuth，是一种允许应用程序或服务在不共享用户的登录凭证的情况下，安全地访问用户在其他服务上的数据的协议。它为第三方应用提供了有限的访问权限，通常用于社交媒体登录、数据共享等场景。这种方法提高了数据安全性，同时也方便了用户和服务之间的数据交互。

一个常见的授权登录示例是使用社交媒体账号登录其他服务或应用。例如，很多网站和应用允许你使用Facebook或Google账号登录。当你选择这种登录方式时，网站会引导你到Facebook或Google的登录页面。在这里，你需要授权该网站访问你的某些社交媒体信息（如基本资料）。一旦授权，你就可以使用社交媒体账号在新网站上登录，而无需创建新的账户。这种方式简化了登录流程，同时保护了你的密码安全，因为你的社交媒体登录信息不会被第三方网站获取。

配合使用

单点登录与授权登录是分开的两套业务，但是可以配合使用，比如，Google Mail 首次登录时，需要使用Google账号授权登录Google Mail，但是登录之后，Google旗下的YouTube、Google Cloud等服务均无需登录(处于已登录状态)，这就是配合使用的情况。目前国内的腾讯旗下几乎所有站点，都采用的是QQ授权登录，网易我尝试了一下，163官网与网易账户中心是SSO，其余都是账号密码登录。

单点登录

为何诞生？

为什么会诞生SSO这种业务呢，主要就是为了方便用户，当一个企业的业务站点过多的时候，用户每一个业务都去注册、登录，无疑会给用户带来体验上的阻碍，而此时，如果使用一种登录一个网站其余网站均为登录状态的技术，这样可以极大的优化用户的体验，无需重复的注册账户和输入密码。但是在最开始，并不是直接使用SSO这样的方案来实现的，且听我娓娓道来。

早期方案

早期的多系统登录常使用同一顶级域名下的cookie共享方法。例如，公司的多个系统的子域名都在“zhaixing.net”下，比如：“blog.zhaixing.net”与“www.zhaixing.net”，它们的主域名都是zhaixing.net，所以这些网站的cookie都是可以共享的，通过共享cookie来实现网站登录的互联。这种方法的局限在于：所有系统必须使用相同的域名和技术平台，且cookie存在安全风险。因此，为了更安全高效地实现多系统登录，逐渐发展到了单点登录（SSO）。

单点登录与早期方案相比

优势：

安全性更高：SSO减少了密码泄露的风险。
用户体验更佳：用户只需登录一次即可访问所有服务。
技术适用性广：支持跨域名和多种技术平台。

劣势：

实现复杂度高：需要更精细的安全和集成设计。
维护成本提高：对于系统间的集成和安全维护有更高要求。

SSO变化

自适应 SSO 需要在一开始登录时输入用户名和密码，但随后如出现其他风险，例如，当用户从新设备登录或尝试访问特别敏感的数据或功能时，就需要额外的身份验证因子或重新登录。
联合 SSO - 更准确的名称是联合身份管理 (FIM)，是 SSO 的扩展。 SSO 基于单个组织域内应用之间的数字信任关系，而 FIM 会将这种关系扩展到组织外部的可信第三方、供应商和其他服务提供商。例如，FIM 允许已登录的员工访问第三方 Web 应用程序（如 Slack 或 WebEx），无需额外登录，或者仅使用用户名来登录。
社交登录允许用户使用他们访问流行社交媒体网站的凭证来访问第三方应用。社交登录简化了用户的生活。对于第三方应用提供商，它可以阻止不良行为（例如，错误登录和购物车遗弃），并为改进其应用提供有价值的信息。

SSO原理

单点登录的原理主要是由下面部分构成：

统一登录入口： 所有系统共用一个登录页面，用户只在这里登录一次。
授权令牌创建： 登录成功后，认证中心会创建一个“令牌”（一种特殊的标记）。
令牌分发： 用户尝试进入其他关联系统时，系统不再要求登录，而是检查这个令牌。
会话建立： 令牌有效，系统就允许用户进入，并为用户建立一个新的会话，就像他们直接登录那个系统一样。

简单来说，SSO就像是“一次登录，到处通行”的方式，提高了访问效率和安全性。

举个例子，想象你去一个大型购物中心，这里有很多商店。在进入商店前，你需要在购物中心的入口处拿到一个入场手环。一旦你在入口验证了身份并拿到手环，你就可以自由进入中心内的任何一家商店，无需在每家商店门口再次出示身份证明。这个手环就像SSO中的授权令牌，一次验证，多处使用。每个商店都信任这个手环的有效性，因此不需要你每次进店都证明自己的身份。又或者，你住酒店，酒店会给你发一张一卡通，这个卡可以刷电梯，可以刷早餐，可以插卡取电...等等。

注：素材图片取自www.cnblogs.com/ywlaker/p/6…

以上的流程图用文字描绘如下：

用户尝试访问系统1的受保护资源：用户首先访问系统1，但由于未登录，系统1将用户重定向到SSO认证中心，并把自己的地址作为参数发送。
SSO认证中心的登录过程：SSO认证中心发现用户未登录，因此引导用户到登录页面。用户输入用户名和密码提交登录申请。
创建全局会话和授权令牌：SSO认证中心验证用户信息后，创建一个全局会话，并生成授权令牌。
用户被重定向回系统1：带着授权令牌，SSO认证中心将用户重定向回最初的请求地址，即系统1。
系统1的验证过程：系统1接收到令牌，并向SSO认证中心查询以验证令牌的有效性。
建立局部会话：验证令牌后，系统1使用该令牌与用户建立一个局部会话，并向用户提供访问受保护资源的权限。
用户访问系统2：用户现在尝试访问系统2的受保护资源。与之前类似，系统2将用户重定向到SSO认证中心。
SSO认证中心识别用户已登录：由于用户已经通过系统1登录，SSO认证中心识别这一点，并带着令牌重定向用户回系统2。
系统2建立局部会话：系统2使用从SSO认证中心收到的令牌与用户建立局部会话，并提供访问权限。

全局会话与局部会话的关系：

如果局部会话（如在系统1或系统2中的会话）存在，那么全局会话（在SSO认证中心中的会话）也一定存在。
全局会话的存在并不意味着每个系统都有局部会话。
当全局会话结束时（比如用户从SSO认证中心登出），所有局部会话也必须结束。

示例：想象一下，有一个用户Tom。Tom首先访问公司的邮件系统（系统1），但需要登录。邮件系统将他重定向到公司的SSO认证中心，Tom在那里登录。登录成功后，他被带回邮件系统，并且可以访问他的邮件。之后，Tom决定查看公司的内部论坛（系统2）。当他点击论坛链接时，系统检测到他已经通过SSO登录，因此直接允许他访问，而无需再次登录。在这个过程中，Tom与SSO认证中心的会话是全局的，而他与邮件系统和论坛的会话是局部的。

SSO和零信任方法

“零信任”采取“从不信任，始终验证”的安全方法：任何用户、应用或设备 - 无论是在网络外部，还是已经通过身份验证并位于网络内部 - 都必须在访问所需的下一个网络资源之前验证其身份。随着网络变得更加分散，跨越的本地基础架构以及私有云和公有云数量更多，零信任方法对于防止渗透网络的威胁获得更多访问权限并造成最大的损害至关重要。 SSO 被广泛视为实施零信任方法的基础技术，尤其是作为 IAM 解决方案一部分的 SSO。零信任的基本挑战是创建一个安全架构，打击渗透网络的攻击者，而不会阻碍获得授权的最终用户在网络中自由行动并完成工作或业务。与多因子身份验证、访问和权限控制、网络微分段等技术和最佳实践相结合后，SSO 可以帮助组织实现这种平衡。

人话：字面意思，谁都不信任，不管是谁，都需要认证，也就是结合授权登录并要求每次每个业务的产品都要授权一次，不再是自由访问同一个主域名下所有站点，而Google就属于没有采取这种模式的情况。

零信任模型的简化解释

“零信任”是一种网络安全方法，其核心理念是“永远不要盲目信任，总是进行验证”。在这种模型下：

无论身份地位：不论是普通用户、高级管理员，甚至是公司CEO，所有人在访问网络资源时都需要验证身份。
无论位置：不论是在公司内部网络，还是外部网络，比如在家或咖啡馆工作，都必须进行验证。
目的：这种方法的目的是防止未授权的访问和减少网络攻击的风险。

SSO在零信任中的角色

单点登录（SSO）在零信任模型中扮演重要角色，因为它是身份和访问管理（IAM）的一部分：

简化登录：SSO允许用户使用一组凭据（如用户名和密码）登录多个相关的服务或应用。这减少了用户需要记住的密码数量，同时也简化了登录过程。
增强安全性：尽管SSO简化了登录过程，但与多因子身份验证（MFA）、访问控制和网络微分段等技术结合使用时，它可以提高安全性。这些技术确保只有经过适当验证和授权的用户才能访问敏感资源。

举例说明

想象一家公司，员工们需要访问电子邮件、文档存储和内部应用程序等多种系统。在零信任模型下：

身份验证：无论员工位于公司办公室还是在家远程工作，他们都需要验证自己的身份才能访问这些系统。
SSO的应用：公司实施了SSO，员工只需使用一组凭据即可访问所有系统。这意味着他们登录一次后，无需为访问其他系统再次输入凭据。
结合MFA等技术：为了增强安全性，除了SSO，还可能要求员工使用多因子身份验证，比如输入密码后还需通过手机应用进行确认，这样即使密码被泄露，未经授权的人也很难登录。

通过这种方式，零信任模型结合SSO可以既提高安全性，又不过度阻碍员工的工作效率。

如何区分不同网站的会话？

会话标识符（Session ID） ：每个局部会话都有一个唯一的会话标识符。这个标识符通常在用户通过SSO登录时生成，并且在用户访问每个不同的系统（站点）时传递给该系统。每个系统根据这个会话标识符来识别和区分不同的用户会话。
令牌和凭证的使用：在SSO环境中，认证中心会发放令牌或凭证给用户。当用户访问不同的站点时，这些站点会根据用户提供的令牌或凭证来创建独立的局部会话。每个站点都会验证这些令牌的有效性，确保用户已经在SSO中心进行了身份验证。
Cookie和本地存储：大多数网站使用浏览器的Cookie来保持用户的会话状态。当用户登录某个系统后，该系统可以在用户的浏览器上设置一个特定的Cookie。这个Cookie通常包含会话ID或其他标识信息，使得该系统在用户再次访问时能识别出具体的用户会话。
子域隔离：如果不同的站点是作为主域的子域运行的，它们可以通过设置特定的Cookie来区分不同的子域。这些Cookie可以配置为只对特定的子域有效，从而帮助区分不同子域下的用户会话。
后端会话管理：服务器端通常会有会话管理机制，用于存储关于每个用户会话的信息，如用户权限、会话持续时间等。这些信息可以帮助系统识别和管理每个独立的用户会话。
客户端和服务器端的同步：为了保持会话的一致性，客户端（如浏览器）和服务器端的会话信息需要同步。这通常通过HTTP请求和响应中的Cookie和头信息来实现。

多种实现方法

单点登录（SSO）的实现方式多种多样，不仅限于使用会话的方式，下面列举出SSO实现的不同方式：

基于会话的SSO：这是最传统的方式，如我之前描述的，通过创建全局会话和局部会话来管理用户的登录状态。在这种方法中，用户的登录状态通常通过服务器端的会话和浏览器端的Cookie来维护。
基于令牌的SSO：在这种方法中，SSO认证中心在用户成功登录后，会生成一个令牌（通常是JWT - JSON Web Token）。用户随后使用这个令牌来访问其他系统。每个系统通过验证这个令牌的有效性来为用户提供服务，而不是通过传统的会话机制。这种方法在RESTful API和微服务架构中非常流行。
OAuth和OpenID Connect：OAuth是一个授权框架，允许应用在用户授权的情况下访问其他应用的功能。OpenID Connect是建立在OAuth 2.0之上的认证层，它允许客户端验证用户的身份并获取基本的个人信息。这些技术常用于实现SSO，特别是在需要跨多个独立域名或应用访问的场景中。
SAML（Security Assertion Markup Language） ：SAML是一个基于XML的开放标准，用于在身份提供者和服务提供者之间交换身份验证和授权数据。SAML广泛用于企业级应用中，尤其是在Web服务和浏览器中实现SSO。
Kerberos：Kerberos是一种基于票据的协议，用于网络认证。虽然它通常用于内部网络认证，但在某些复杂的企业环境中，Kerberos也被用于实现SSO。
联邦身份管理：这是一种更为广泛的SSO概念，涉及多个组织和服务之间的身份共享。在这种模型中，用户在一个组织（身份提供者）的身份验证可以被其他多个组织（服务提供者）所接受。

每种SSO实现都有其优点和适用场景。选择哪种方法取决于多种因素，如安全要求、系统架构、易用性和维护成本等。随着云服务和微服务架构的兴起，基于令牌的SSO和使用OAuth/OpenID Connect的方法变得越来越流行。不够目前我使用的最多的，就是基于Token的SSO实现了，也就是令牌的方式，而且一般实现Token令牌的策略时，一般Token也会有一个自定义的Session作为其他用途，然后就是Oauth2.0可能比较多。

注销登录

注：素材图片取自www.cnblogs.com/ywlaker/p/6…

以上的流程图用文字描绘如下：

用户向系统1发起注销请求：设想用户当前登录在系统1（比如一个邮件服务），并希望注销。用户在系统1中点击注销按钮。
系统1发起注销请求至SSO认证中心：系统1使用用户的会话ID来识别用户，并将这个信息作为注销请求发送到SSO认证中心。
SSO认证中心处理注销请求：SSO认证中心验证从系统1收到的令牌。一旦验证通过，它将销毁与用户相关的全局会话。
通知所有注册系统执行注销操作：SSO认证中心接着获取所有使用该用户令牌注册的系统地址，并向这些系统发送注销请求。
注册系统销毁局部会话：每个收到注销请求的系统（如系统2，一个内部论坛服务）都会接收到来自SSO认证中心的请求，并销毁与该用户相关的局部会话。
用户被重定向到登录页面：最后，SSO认证中心将用户重定向到登录页面，表示注销过程已完成。

示例：比如，Alice在她的工作地点使用了邮件系统（系统1）和内部论坛（系统2）。她首先登录邮件系统，然后无需再次登录即可访问论坛。当Alice在邮件系统中点击注销时，邮件系统将这个请求发送给SSO认证中心。SSO认证中心确认后，通知(或者是前端主动拉取状态)论坛系统Alice已注销。接着，论坛系统销毁与Alice相关的会话。在这个过程中，Alice的全局会话和所有相关的局部会话都被销毁，确保她在所有系统中都成功注销，最后，Alice被重定向回登录页面。

架构与业务

注：此图片取自www.cnblogs.com/ywlaker/p/6…

sso-client

拦截未登录请求：当用户尝试访问子系统（如公司内部网站）时，如果未登录，sso-client将拦截这个请求，并将用户重定向到sso-server（SSO认证中心）。
接收和存储令牌：用户在sso-server成功登录后，sso-client接收并存储从sso-server发来的授权令牌。
校验令牌：sso-client与sso-server通信，验证接收到的令牌的有效性。
建立局部会话：一旦令牌验证通过，sso-client为用户在子系统中建立局部会话。
处理注销请求：当用户在子系统中请求注销时，sso-client会将注销请求发送到sso-server。
接收注销指令：sso-client还能接收来自sso-server的注销请求，并据此销毁用户的局部会话。

sso-server

验证登录信息：sso-server负责验证用户提交的登录信息。
创建全局会话：验证成功后，sso-server为用户创建全局会话。
生成授权令牌：sso-server创建授权令牌，并在需要时发送给sso-client。
发送令牌：sso-server与sso-client通信，发送授权令牌以便建立局部会话。
校验令牌：sso-server验证从sso-client发来的令牌请求，以确保其有效性。
系统注册：sso-server负责注册子系统，以便管理它们的认证请求。
处理注销请求：sso-server接收来自sso-client的注销请求，并据此销毁全局和所有相关的局部会话。

示例

假设Alice在工作时需要访问公司的邮件系统（系统A，一个sso-client）和人力资源管理系统（系统B，另一个sso-client）。当Alice首次尝试访问系统A时，她被重定向到sso-server（SSO认证中心）进行登录。登录后，sso-server创建一个全局会话和一个授权令牌，并将这个令牌发送回系统A。系统A接收令牌，验证其有效性，并为Alice在其系统内创建一个局部会话。接着，当Alice访问系统B时，由于她已经在sso-server登录，系统B可以通过与sso-server的通信来确认她的身份，并为她创建另一个局部会话，无需她重新登录。如果Alice在任一系统中注销，sso-client会通知sso-server，后者随即销毁全局会话，并通知所有相关的sso-client销毁它们的局部会话。

大概编码

注：编码部分使用AI生成，不一定准确，仅供参考，如果想要准确的代码，可以查看开源的XXL-SSO项目。

ChatGPT使用了SpringSecurity框架，我不太建议使用它，我建议使用Sa-Token权限框架或者自己手写一个简单的权限模块会更好。要使用Spring Boot实现一个简单的单点登录（SSO）系统，包括 sso-server 和 sso-client，您需要创建两个独立的Spring Boot项目：一个用于sso-server，另一个用于sso-client。我将向您展示如何搭建基本结构和关键配置。请注意，为了简化，这里的例子仅作为入门级演示，并非生产级代码。

创建 sso-server

Maven 依赖： 在 pom.xml 文件中，添加以下依赖：

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
    <!-- 其他依赖... -->
</dependencies>

Spring Security 配置：创建一个配置类来设置Spring Security。

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // author JanYork
        http
            .authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .formLogin()
            .and()
            .csrf().disable();
    }
}

用户信息服务：提供一个简单的用户信息服务。

@Service
public class UserService implements UserDetailsService {

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        // 这里应该连接到您的用户数据库，下面仅为示例
        if ("admin".equals(username)) {
            return new User("admin", "password", new ArrayList<>());
        } else {
            throw new UsernameNotFoundException("用户未找到");
        }
    }
}

创建 sso-client

Maven 依赖：同样在 pom.xml 中添加Spring Boot和Spring Security依赖。

Spring Security 配置：设置安全配置，以连接到 sso-server。

@Configuration
@EnableWebSecurity
public class ClientSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .oauth2Login()
            .and()
            .csrf().disable();
    }
}

资源控制器：创建一个简单的控制器来测试认证。

@RestController
public class TestController {

    @GetMapping("/")
    public String home() {
        return "欢迎来到SSO Client!";
    }
}

运行和测试

启动 sso-server：运行 sso-server 应用。
启动 sso-client：运行 sso-client 应用。
访问客户端：在浏览器中访问客户端应用。由于客户端配置了OAuth2登录，您将被重定向到sso-server进行认证。
登录并重定向：在 sso-server 登录后，您将被重定向回客户端应用。

注意

本例中未包含OAuth2服务器的配置，这通常更复杂，涉及客户端和服务端的注册以及令牌服务。
在实际应用中，您可能需要使用更高级的身份验证和授权服务器，如Keycloak或Auth0。
这个例子仅展示了基本结构。在实际部署时，您需要考虑更多因素，如HTTPS配置、令牌的安全性、会话管理等。

要实现完整的SSO解决方案，您可能需要花费更多时间来深入研究Spring Security、OAuth2协议以及相关的最佳实践。

授权登录

为何诞生

授权登录诞生的主要原因是为了在保护用户隐私和安全的前提下，实现跨应用程序或服务的数据访问和功能共享。它解决了传统登录方法中用户凭据（如用户名和密码）需要被多个应用程序共享的问题，减少了数据泄露风险，并简化了用户操作流程。同时很多服务商都设立有开放平台，可以让其他公司或者个人产品使用对应的授权登录，从而实现了部分社会便利性。

Oauth2.0是什么？

OAuth 2.0是一个行业标准的授权协议，允许用户授予第三方应用对自己在某个服务上的特定数据的有限访问权限，而无需将自己的登录凭据（用户名和密码）提供给第三方应用。它定义了几种授权流程，适用于不同的客户端环境和使用场景。

要去详细的了解Oauth的话还是有些麻烦的，这里就不多说了，如果有需要，小简可以在下一次写一篇Oauth相关的文章。

授权登录原理

授权登录的基本原理涉及以下几个关键步骤：

用户授权请求：用户尝试通过第三方应用访问服务时，第三方应用请求用户的授权。
重定向到授权服务：用户被重定向到服务提供者的授权页面，以登录并确认授权。
授权码发放：服务提供者验证用户身份并提供一个授权码给第三方应用。
获取访问令牌：第三方应用使用授权码向授权服务器请求访问令牌。
访问受保护资源：第三方应用使用访问令牌请求用户的数据。

常见的授权登录服务

Google：提供OAuth 2.0服务，允许第三方应用访问Google用户的基本信息、邮件、日历等。
Facebook：允许用户使用其Facebook身份在其他应用或网站上登录，并分享信息。
GitHub：提供OAuth服务，使第三方应用可以请求用户的GitHub数据。
微信：在中国广泛使用的OAuth服务，允许通过微信账号登录第三方应用。

架构与业务

在一个典型的授权登录架构中，涉及三个主要角色：

用户（资源所有者）：拥有可被访问的数据或服务。
客户端应用（第三方应用）：希望访问用户在服务提供者上的数据。
服务提供者（授权服务器和资源服务器）：存储用户数据的平台，提供OAuth服务。
业务流程中，用户首先在客户端应用上发起登录或数据访问请求。
客户端应用将用户重定向到服务提供者的授权页面，用户在该页面上进行登录并授权。
授权后，服务提供者向客户端应用发放授权码，客户端应用再用该授权码换取访问令牌。
最后，客户端应用使用这个令牌访问用户在服务提供者上的受保护资源。

通过这种方式，OAuth为用户提供了一种安全的方式来允许第三方应用访问其在不同服务上的数据，而无需暴露其登录凭证。这不仅提高了安全性，同时也提供了更好的用户体验，因为用户无需为每个应用或服务创建和记住新的账户信息。

编码，尝试接入第三方授权登录

注：编码部分使用AI生成，基本上不准确，仅供参考，如果需要实际使用，可以直接使用开源项目JustAuth，几乎集成了市面上常用的第三方授权登录服务，只需要简单配置就可以实现。

要使用Spring Boot实现一个授权登录业务，通常会结合Spring Security和OAuth 2.0。以下是一个简单的授权登录实现的概要步骤，假设我们正在创建一个允许用户通过Google账户登录的应用。

创建Spring Boot项目

首先，创建一个新的Spring Boot项目。可以使用Spring Initializr来快速生成项目结构。

添加依赖

在项目的pom.xml文件中添加必要的依赖。主要包括Spring Boot Starter Web、Spring Boot Starter Security和Spring Security OAuth2 Client。

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-oauth2-client</artifactId>
    </dependency>
    <!-- 其他依赖... -->
</dependencies>

配置应用程序

在application.properties或application.yml文件中，添加OAuth 2.0客户端配置。你需要在Google Cloud Platform上创建一个OAuth 2.0客户端ID和密钥，并将它们添加到配置中。

spring:
  security:
    oauth2:
      client:
        registration:
          google:
            clientId: [Google-Client-ID]
            clientSecret: [Google-Client-Secret]
            scope: 
              - email
              - profile

安全配置

创建一个安全配置类，配置Spring Security以使用OAuth 2.0进行登录。

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests(authorizeRequests -> 
                authorizeRequests
                    .antMatchers("/", "/home", "/error", "/webjars/**").permitAll()
                    .anyRequest().authenticated()
            )
            .oauth2Login();
    }
}

创建控制器

创建一个简单的控制器来处理登录和用户信息的显示。

@Controller
public class WebController {

    @GetMapping("/")
    public String home() {
        return "home";
    }

    @GetMapping("/user")
    @ResponseBody
    public Principal user(Principal principal) {
        return principal;
    }
}

前端页面

创建一个简单的前端页面（如home.html），在其中添加一个登录链接。

<!DOCTYPE html>
<html>
<head>
    <title>Home</title>
</head>
<body>
    <h2>Welcome</h2>
    <a href="/oauth2/authorization/google">Login with Google</a>
</body>
</html>

运行和测试

运行应用程序并访问主页。点击“Login with Google”链接，你将被重定向到Google的登录页面。登录后，Google将重定向回你的应用，并且你可以访问受保护的用户信息。

注意事项

保证安全性：在部署生产环境时，确保使用HTTPS。
配置Google Cloud Platform：正确配置OAuth 2.0客户端并获取必要的凭据。
用户体验：根据应用需求调整前端页面和用户流程。
数据处理：根据业务需求和隐私政策处理用户数据。

这个例子提供了一个基本的授权登录流程实现框架。根据具体的业务需求，你可能需要进一步定制安全配置、用户信息处理逻辑等。

编码，尝试写一个自己的授权服务

注：编码部分使用AI生成，不一定准确，仅供参考。

要实现一个基于Spring Boot的OAuth2授权登录服务，我们将创建两个项目模块：一个作为授权服务器（server），另一个作为客户端（client）。下面分别说明这两个模块的基本设置和实现。

授权服务器（Server）模块

创建项目：
- 使用Spring Initializr创建一个新的Spring Boot项目，命名为AuthServer。
添加依赖：
- 在pom.xml中添加Spring Security和OAuth2依赖。

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.security.oauth</groupId>
        <artifactId>spring-security-oauth2</artifactId>
        <version>2.4.0.RELEASE</version>
    </dependency>
    <!-- 其他依赖... -->
</dependencies>

配置授权服务器：
- 创建一个配置类来设置OAuth2授权服务器，定义客户端详情和授权类型。
用户信息服务和安全配置：
- 实现UserDetailsService来提供用户认证，并配置Spring Security。

客户端（Client）模块

创建项目：
- 使用Spring Initializr创建一个新的Spring Boot项目，命名为AuthClient。
添加依赖：
- 在pom.xml中添加Spring Boot Starter Web和OAuth2客户端依赖。

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-oauth2-client</artifactId>
    </dependency>
    <!-- 其他依赖... -->
</dependencies>

客户端配置：
- 在application.properties或application.yml中配置OAuth2客户端信息，指向授权服务器。
控制器和视图：
- 创建控制器处理登录和用户信息的显示，以及相应的前端页面。
运行和测试：
- 启动授权服务器和客户端应用，进行登录流程测试。

注意事项

安全性：在生产环境中，请使用HTTPS来确保数据传输的安全性。
数据存储：在实际应用中，你应该将用户信息存储在数据库中，并且应用加密措施来保护用户数据。
配置：在实际部署中，OAuth2的配置可能会更加复杂，包括令牌增强、客户端权限配置等。

通过这种方式，你可以设置一个完整的OAuth2授权登录流程，其中授权服务器负责用户认证和令牌发放，客户端负责向用户展示登录界面并使用授权服务器提供的服务。

总结与摘要

单点登录（SSO）

核心概念：允许用户使用单一凭证访问多个应用或服务。
优势：减少记忆负担，提升安全性和用户体验。
应用：例如，使用Google账号可访问所有Google服务。

授权登录

定义：允许应用在不共享用户凭证的情况下访问用户在其他服务的数据。
优势：增强数据安全性，简化用户体验。
例子：使用社交媒体账号登录其他应用或服务。

SSO结合授权登录

整合方式：SSO和授权登录可结合使用，提供更全面的安全和用户体验。例如，通过Google账户进行OAuth授权登录后，用户可自动登录所有Google服务。
应用场景：适用于需要跨多个独立系统或应用提供无缝用户体验的场景。

其他

安全性与便捷性：SSO和授权登录共同增强安全性，同时提供便捷的用户访问流程。
技术选型：根据业务需求选择合适的SSO方案和授权登录方法。
实现注意事项：确保数据传输和存储的安全性，尊重用户隐私。

感谢大家能够阅读完这一篇长篇幅的文章，虽然看起来简单，但是只有详细深入的了解业务，才可以真正优雅的实现需求。

本文参与腾讯云自媒体分享计划，分享自作者个人站点/博客。

原始发表：2024-03-05，如有侵权请联系 cloudcommunity@tencent.com 删除

配置

系统

单点登录

服务

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体分享计划，欢迎热爱写作的你一起参与！