在本文中，我们学习如何使用Spring boot轻松配置和部署微服务，然后使用OAuth和OpenID保护它们。

在微服务体系架构中，其中较大的应用程序由多个较小的服务组成，每个服务都有自己的目标，它们通过网络进行协作和通信，以实现特定的目标。在微服务体系结构中，每个服务都在自己的进程中运行，并使用轻量级机制（如HTTP/REST和JSON）与其他进程通信。

微服务，它为项目工程、可扩展性和性能提供了好处。将单个应用程序划分为不同的组件意味着可以同时开发和部署每个组件，但又可以分别进行。

当我们将微服务体系结构与单片应用程序设计进行比较时，它就更有意义了。在单片体系结构设计中，我们创建了一个大的、笨重的应用程序，所有模块都紧密耦合在一个可执行文件中，这个可执行文件通常部署在Web或应用服务器上。

典型的单片架构应用程序如下所示：

微服务示例：

微服务设计的关键指南

• 松耦合、独立和高性能

• 独立的扩展、部署、监视和管理，不影响任何其他应用程序或服务

• 单一责任原则

• 更快的开发和发布周期

Spring Boot概述

首先，Spring Boot不是一个框架，它是一种轻松创建具有最小配置或零配置的独立应用程序的方法。 这是一种开发基于敏捷开发的应用程序的方法，配置非常少。 它提供了代码和注释配置的默认值，可以在短时间内快速启动新的Spring项目。

为什么选择Spring Boot？

• 使用Java开发基于Spring的应用程序非常容易。

• 它减少了大量的开发时间并提高了生产率。

• 它避免编写大量的样板代码，注释和XML配置。

• 将Spring Boot应用程序与Spring生态系统集成在一起非常容易，如Spring JDBC，Spring ORM，Spring Data，Spring Security等。

• 它提供了嵌入式HTTP服务器，如Tomcat和Jetty，可以非常轻松地开发和测试Web应用程序。

为什么Spring Boot用于微服务？

第一个好处是Spring Boot通过将Spring应用程序中的Convention over Configuration（CoC）提升到一个全新的水平，大大简化了应用程序配置。Spring Boot有一个称为自动配置的功能，可以智能地提供一组由类路径上的jar驱动的默认行为。因此，在保留定制应用程序的能力的同时，很容易在很少或没有配置的情况下启动和运行新的微服务。

Spring boot的第二个好处是，它允许您将应用程序打包为包含预配置的嵌入式Web容器（Tomcat或Jetty）的可执行JAR，从而简化了部署。这样就无需在服务器上安装和配置Tomcat或Jetty。相反，要运行微服务，只需安装Java即可。此外，可执行JAR格式提供了一种统一的、自包含的方式来打包和运行JVM应用程序，而不管其类型如何，这简化了操作。

为什么要考虑微服务安全？

当您的项目从一个整体架构转移到微服务架构时，安全性可能是一个重要方面。微服务体系结构本质上是高度分布的，其特点是网络流量增加。通常，业务数据可以通过RESTAPI访问，如果不正确地保护它们，则很容易被盗。这些调用应该通过使用HTTPS协议来防止中间节点攻击，但是API端点也必须是安全的。安全检查的工作应该与调用微服务API的工作很好地平衡，否则您的体系结构将永远无法很好地执行。为了保护每个服务节点，每个微服务都应该获得一个标识和一组权限，以便API端点安全组件能够验证这两者。

使用OAuth 2.0的Spring安全性

关于OAuth到底是什么有很多困惑。

有些人认为OAuth是一个登录流（比如，当你使用微信登录登录到一个应用程序时），有些人认为OAuth是一个“安全的东西”，实际上并不了解更多。

我将引导您了解OAuth是什么，解释OAuth是如何工作的，并希望让您了解OAuth如何以及在何处对您的应用程序有利。

什么是OAuth 2.0？

首先，OAuth不是API或服务：它是一个开放的授权标准，任何开发人员都可以实现它。

OAuth是应用程序可以用来向客户端应用程序提供“安全授权访问”的标准。OAuth通过HTTP工作，并使用访问令牌而不是凭据来授权设备、API、服务器和应用程序。

OAuth有两个版本：OAuth 1.0和OAuth 2.0。 这些规范彼此完全不同，不能一起使用：它们之间没有向后兼容性。

OAuth 2.0的作用是什么？

OAuth基本上是一个支持授权工作流的协议。这意味着它为您提供了一种确保特定用户具有执行某项操作的权限的方法。

OAuth并不是要做像验证用户身份这样的事情——这是由身份验证服务负责的。身份验证是指验证用户的身份（如要求用户名/密码登录），而授权是指检查现有用户已经拥有的权限。

为什么选择OAuth 2.0？

轻松：朋友会向您发送有趣图片或视频的链接，您想发表评论。唯一的问题是，你以前从未去过这个网站，也没有帐户。当你花几秒钟考虑是否值得注册时，你会看到一个“用你的微信帐户登录”按钮。成功！你是数亿微信用户中的一员，所以这是一个非常简单的OAuth替代方案。

安全性：自从OAuth 2.0（现在是标准模型）问世以来，所有OAuth数据传输都必须在SSL（安全套接字层）上进行，以确保使用最可信的加密行业协议尽可能地保证数据的安全。

受欢迎程度：。OAuth已经被腾讯，阿里，百度，谷歌、Facebook、Twitter等公司所采用。

时间：不仅很容易，而且从长远，这是非常节省时间的。无论是在网上找到一个新的网站还是返回到最喜欢的网站，如果你经常访问支持OAuth的网站，那么你只需要为你访问的网站授权创建一个帐户即可。这就相当于晚上去一个新的俱乐部，让一个非常酷的朋友带你走到队伍的最前面，让保镖举起绳子让你绕开漫长的等待。

OAuth 2.0示例

一位外宾A对接待处说，他想与员工B见面，以方便商务活动。

接待处通知员工B，客人A来拜访他。

员工B来到接待处，确认客人A的身份。

员工B在前台记录客人A的业务目的和身份。

接待处向A客人发放访客卡。

员工B和客人A去指定的房间讨论他们的业务。

我给出这个示例是为了帮助您理解签发OAuth和授权的过程。访客卡只允许访客进入预先确定的地方，这意味着持有“访客卡”的人不能进入持有“员工ID卡”的人可以进入的所有地方。这样，直接登录服务的用户可以做的比OAuth授权的用户多。

在OAuth中，“auth”是指“授权”和“身份验证”，因此，在执行OAuth的身份验证时，服务提供商（接待台）会询问用户（员工）是否希望授权第三方应用程序（来宾）的请求。下图显示了Facebook如何询问您是否要授予对第三方应用程序的访问权限。

OAuth 2.0-关键概念

至少，您应该了解OAuth2中的四个关键概念：

• OAuth2角色

• OAuth2授权授予类型

• OAuth2令牌

• OAuth2令牌访问范围

• 让我们一个接一个地讨论关键概念。

OAuth 2.0角色

OAuth 2.0定义了四个角色：

资源所有者：一般是你自己。能够授予受保护资源访问权的实体。当资源所有者是一个人时，它被称为最终用户。

资源服务器：托管受保护数据的服务器

客户端应用程序：请求访问资源服务器的应用程序
授权服务器：服务器向客户端发出访问令牌。 此令牌将用于客户端请求资源服务器。

OAuth 2.0授权：

授权是表示客户端用于获取访问令牌的资源所有者授权（访问其受保护资源）的凭证。规范定义了四种授权类型：

授权代码：一旦客户端是Web服务器，就应该使用它。 它允许您获取长期访问令牌，因为它可以使用刷新令牌续订（如果授权服务器启用它）。

隐式：通常在客户端使用脚本语言（如Javascript）在浏览器中运行时使用。 此授权类型不允许发布刷新令牌。

资源所有者密码凭据：当客户端和服务器都来自信任所在的同一公司时，最适合授予“密码凭据”，您不想向第三方提供凭据。

客户端凭据：当客户端本身是资源所有者时，使用这种类型的授权。没有从最终用户获得授权。

OAuth 2.0令牌

令牌是由授权服务器生成的随机字符串，在客户机请求时发出。

令牌有两种类型：

访问令牌：此令牌由客户机作为参数或作为请求中的头发送到资源服务器。它的生存期有限，由授权服务器定义。它必须尽快保密，但我们会发现这并不总是可能的，特别是当客户机是通过javascript向资源服务器发送请求的Web浏览器时。

刷新令牌：它只在访问令牌过期时发送到授权服务器以更新访问令牌。出于安全原因，不可能总是获得此令牌。

OAuth 2.0令牌范围

客户端可以使用作用域[要访问此用户帐户的源和照片]和授权服务器请求具有特定访问权限的资源，然后返回显示实际授予客户端哪些访问权限的作用域[例如，资源所有者仅允许源访问，没有照片]。

访问令牌可以通过多种方式发送到资源服务器。

请求参数（GET或POST）：
                使用GET的示例：
               https://api.example.com/profile?access_token=MzJmNDc3M2VjMmQzN
授权标题：
                GET / profile HTTP / 1.1
                主持人：api.example.com
                授权：Bearer MzJmNDc3M2VjMmQzN

OAuth 2.0流程

这里我们有两个端点：
授权端点
令牌端点
还有资源所有者Joe。

因此，必须有两件事来实现这个OAuth：

Joe应该拥有Gmail帐户。
我的应用程序应该在Google注册。

因此，我的应用程序向Authorization Endpoint发送请求，在此请求中，它只是说这是我的客户端ID。在这里，它没有发送密钥。我想访问这些电子邮件。它没有具体说明哪个电子邮件。它只是说资源的类型。因此，OAuth验证了这一点，当事情正常时，它会将请求转发给资源所有者并说：“嘿资源所有者，首先我希望您进行身份验证。” 这通过将登录页面发送给资源所有者来实现。资源所有者通过将他的用户ID和密码发送到auth服务器来验证自己，并且在验证之后，另一个网页生成并告诉资源所有者，名为My App的应用程序想要访问您的电子邮件。它询问您是否要允许访问电子邮件。通常，用户可以选择在屏幕上单击“是”或“否”。大多数情况下，用户说是，然后请求返回到Auth服务器。

此后，auth服务器生成auth代码，然后返回到应用程序my app。现在，是时候验证我的应用了。这意味着现在我们要验证应用程序的身份。我们怎么做？我们用红色钥匙来做。红键是客户机ID，尤其是客户机机密，它只为应用程序和OAuth服务器所知。为了进行验证，如果客户机ID和客户机机密相同（如果您的重定向URI匹配），它会将身份验证代码、客户机ID和客户机机密发送到令牌端点。所有这些检查都在令牌端点完成。

如果一切正常，则生成访问令牌并将其发送回应用程序，即“我的应用程序”。现在，访问令牌需要安全地存储它。通常，令牌有效。现在，应用程序将访问令牌发送到资源服务器并说“这是访问令牌。我想访问电子邮件。” 现在，资源服务器必须验证令牌是否有效。在这种情况下，资源服务器将令牌发送到OAuth服务器令牌端点，并且服务器在数据库中检查令牌是否有效，是否已过期，以及它是否包含正确的范围。

在所有这些检查之后，结果将作为有效或无效的结果返回到资源服务器。如果一切都有效，资源服务器将向资源发送请求，并获取数据并将其发送到应用程序“我的应用程序”。

OpenID连接

OpenID Connect是OAuth 2.0协议之上的一个简单标识层，它允许计算客户端根据授权服务器执行的身份验证来验证最终用户的身份，并获取有关最终用户的基本配置文件信息。

OpenID与OAuth 2.0
OpenID是一种标准的身份验证协议，它也使用HTTP，就像OAuth一样。 但是，OpenID的目的与OAuth的目的不同。

OpenID的主要目的是身份验证，而OAuth则是授权。 因此，使用OpenID基本上与登录相同。 对于OpenID，OpenID Provider处理用户身份验证过程。 许多依赖Open ID的参与者将身份验证委托给OpenID提供商。

除了授权之外，OAuth还具有其身份验证过程。例如，当使用Facebook OAuth时，Facebook服务提供商会对Facebook用户进行身份验证。但是，OAuth的基本目的是确定用户是否有权调用API在用户网页上书写，或者API获取好友列表。

您可以使用OAuth进行用户身份验证；但是，请注意，它的基本目的是授权用户。这与OpenID的目标不同。

为何选择OpenID？
注册更快更容易
登录更快捷，更轻松
更接近统一的“网络身份”

关于OpenID的更多信息

长按订阅更多精彩▼