【Demo视频】使用 Spring Security 5.0 为新一代 OAuth 提供支持

Spring Security有很多认证的功能，其中一个特点是：注册的时候是可以使用外部认证的，比如facebook登录的时候就可以实现。还有它的授权请求，登录以后可以得到用户的信息，因为需要这些用户的信息跟Spring Application进行整合。

我们首先需要注册，因为我们是要Google或者是facebook进行登录，我们需要code。比如，它需要你的账户信息。我们先看一下GitHub。先到setting，找到OAuth App，注册一个新应用。每一个第三方的信息不一样，起始页的有些东西不太相关，有些相关的都是rerote的。先注册一下我的Application，这样我就有了ID和序列号。

接下来我们来配置一下应用。有了这些认证的信息，就有了GitHub，我可以跟GitHub的账户进行同步，跟Facebook都是类似的情况，这样就可以重新导入到GitHub。用认证信息进行登录，有两个认证，我把信息输入进去。

这是大家非常熟悉的登录界面，特别是外部的认证机构。这是我登录的案例。这个Application需要读取你的GitHub的信息，还有一些公司的信息，你点“可以授权”，这后面会有一些动作，有一些终端的信息，所有都要进行整合同步，会花一点时间。

下面说一说OAuth 究竟是怎么样运行的。

第一步，OAuth登录的特点，Code是让自己进行定义，首先要认证request，要配置我自己的信息。

第二步就是tocon。request，当我在演示中点GitHub，GitHub就可以得到这些背景资料。这时一个defot，你只要of/。输入以后就可以往前进行。它会把这个request重新发给开发者，最终的用户要进行认证。

跟大家说一说总体的过程是什么样子的，Authorization会有一些点，它会进行反应，定义范围，这样你就可以知道gateup是什么样子的，有什么信息。state进行一些响应和配置。GitHub进行授权后，它就会进行反馈。

这里是第二步，有了认证以后就可以登录。我点击同意，GitHub就会认证这样一个程序，这样就会创建一个“认证授予”，因为我用的是Code Grant，这样就创造出了代码。然后再回到state，回到在之前request时的state。这是OAuth2.0的标准程序。

再看看运行。先输入了request，然后进行过滤器，这个过滤器就是Code Grant，它来处理这些请求，然后有matcher看看你的信息跟账户的信息是不是一致。这个是可以进行配置的，你可以在这个框架当中进行定义，从而让你看一下它是不是一致，是不是match。到了注册的仓库，它会有不同的注册信息，它可以说是原数据，客户的数据、名字、客户的ID、客户的秘密等等。

然后再进行原数据的检索，创建这样的注册名录库。可以把它的注册和需求连接在一起。总的来讲，我们就是通过这样的界面进行授权，这样可以让我们提纲挈领的了解授权必须进行的步骤。同时，也包括客户的要求。因为客户的要求是不一样的，你需要进行定制，不同的提供者提供不同的参数。通过这样一种做法，如果说是设置一个默认值，它就是按照你设置的默认值来进行运行，但它也可以进行定制。这也是授权要求下所进行的步骤。

客户的数据包括什么呢？包括他的ID，他的其他的相关信息，我们把这些信息收集起来，SpringBoot也有这样的Class，也是属于这种不同属性的设置。我们这些应用是可以进行configuration的，这种应用取决于使用OAuth的哪一个版本。除此之外，还有其他的文件，有一些配置是不会变化的。大家可以看到有一个默认的登录页。

这是一些新的属性的配置。在现有的Spring Boot里面，OAuth里面可以帮我们存储客户的信息。与此同时，你还可以创建多个客户的信息。客户的KPI、绩效等等。你可以在Security下面进入不同的级别，它可以是任何的事物，不管你想要config什么，两层就是gateup。它可以帮助我们快速进行客户注册。

现在看一下OAuth的标准流程。第一步是被导入，第二步是授权。又重新把你导入到这样的浏览器，让客户这个浏览器获得通行证代码。

首先我们是有一个Authorization，然后是通行许可。这是我们得到的两个通行的步骤。如果有人发出这样的需求，你可以根据这样的授权体系来进行授权。但是，不同的授权服务器有不同的做法，有些情况下可能叫做GWT，有些叫做客户的证书，名字不一样。但是，它有一个最基本的流程。同时，还会帮助客户保存他们的信息。授权码最终变成了给客户的通行证。同时，进行链接，让客户获得通行证。令牌需要我们进行前期的工作，在最终授予到客户。在这个过程中，它能够让你自动进行更新，还包括它的截止日期。时间其实是非常快的，大概不到1秒。

另外还有一个Open ID，它和我们说的Token Request是一个意思。授权其实也就是身份的证书，其中就包含最终用户的真实性的考证。这个都是由授权服务器进行的，它就是要负责认证最终用户，保证他是真正的。Google是我们的OpenID的previder，Google就负责这个问题。nonce可以发出防伪的要求，跟最终办法的授权证书是相匹配的。另外该包括exp，什么时候到期。Open ID Connect都是防伪的，它在整个工作流中是不可或缺的。认证可以让我对Spring Security进行认证。它是怎么做的呢？

我们看到授权反馈已经回来了，现在所发生的是客户已经有了授权码，他需要通行证。接下来的流行要继续往下走，除此之外还有其他的过滤器，它会对授权的反馈进行过滤。根据这样的流程，解决客户的需求，所有这些流程都跟授权是相关的，而且两者是连接在一起的，能够帮助我们把授权的需求存储下来。所以，我们要做的第一件事情就是解决当授权的要求被发过来之后，我们用它响应授权的要求，这两者是关联在一起的。过滤器可以确保没有任何的攻击。所以，这种关联是非常重要的。

如果没有任何问题，我们获得了授权的要求，进行授权，发放令牌。最终，就是授予令牌。然后，我们又要进行防伪，这也是最重要的一点。如果说整个流程都走完，就证明它被验证通过了。刚才我讲的作为步骤都是和授权码结合在一起的，信息都被储存在这样的通行证里面。这是Security非常重要的。对于授权码来说，我们也是有Authorization Code，有一个防伪的工具。在这个过程中，我们有另外一个token exchange，你可以进行认证登录，认证码最终被转化成令牌，这也是在整个令牌设立的过程中所必须的。通行证也会发出反馈，反馈到系统。这里是用各种各样不同的ID Token，它也是OpenID的连接平台。这些令牌帮助我们完成工作流。进行信息的处理，服务器把信息传回来，我们又过得了这些信息。通行证也有一个相应的保护资源。

首先，这个客户发出通行证需求的指令，授权服务器会进行回应。它将授予令牌，OpenID被反馈到OAuth1.0。

现在我们已经有了令牌，防伪的过程已经完成。OpenID Connect定义，帮我们找到客户的需求是什么，这些需求包括主观的事务问题等等，他们的诉求要得到满足。比如，我的名字叫Joe，这个就是我的名字排列的格式。在我的名字的组合方式里，它是标准的。在Open ID Conection里面，它不是这样标准的。在演示中，我们要看得更细一点，还需要相应的配置来整合用户资源。

我们有ex-Token，通过Authorization的防护步骤，我们就有了非常有名的部分。这是我们在ID Token获得的反馈信息。因为不同的授权流，ID Token是可以提供的。就像我的姓名，我们需要对它实现标准化的设置。

这是其中的一个例子。

GitHub是一个非标准的，就像我之前提到的那样，作为一个标准的OAuth2.0，我们也对此进行了研究。我们在Spring Security里面进行了很多新功能的嵌入和研究，我们需要知道GitHub的意思到底是什么。如果结构不是标准的，会产生什么样的影响。我们需要找到出现问题的地方。我们是有subject，必须要进行识别。

它是怎么样运行的呢？之前我们也谈到了怎么样获得用户信息资源和防伪的过程。

接下来一步，会看到User服务器，这也是User可以发挥影响力的地方。它重新又回到用户属性，用户要求Open ID Connet的指令要求。在Spring的系列产品中，我们都是遵循了这样的原则，基于ID Connet的基础上来实施。同时，我们也设立了相应的原则，OIDC User。现在我们有了防伪和验证的流程。