Spring Cloud(5):保护微服务 - OAuth2.0的介绍

OAuth2是一个授权(Authorization)协议。我们要和Spring Security的认证(Authentication)区别开来,认证(Authentication)证明的你是不是这个人,而授权(Authorization)则是证明这个人有没有访问这个资源(Resource)的权限。
下面这张图来源于OAuth 2.0 authorization framework RFC Document,是OAuth2的一个抽象流程。

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

先来解释一下上图的名词:

  Resource Owner:资源所有者,即用户

  Client:客户端应用程序(Application)

  Authorization Server:授权服务器

  Resource Server:资源服务器

再来解释一下上图的大致流程:

(A) 用户连接客户端应用程序以后,客户端应用程序要求用户给予授权

(B) 用户同意给予客户端应用程序授权

(C) 客户端应用程序使用上一步获得的授权(Grant),向授权服务器申请令牌

(D) 授权服务器对客户端应用程序的授权(Grant)进行验证后,确认无误,发放令牌

(E) 客户端应用程序使用令牌,向资源服务器申请获取资源

(F) 资源服务器确认令牌无误,同意向客户端应用程序开放资源

从上面的流程可以看出,如何获取授权(Grant)才是关键。在OAuth2中有4种授权类型:

1. Authorization Code(授权码模式):功能最完整、流程最严密的授权模式。通过第三方应用程序服务器与认证服务器进行互动。广泛用于各种第三方认证。

2. Implicit(简化模式):不通过第三方应用程序服务器,直接在浏览器中向认证服务器申请令牌,更加适用于移动端的App及没有服务器端的第三方单页面应用。

3. Resource Owner Password(密码模式):用户向客户端服务器提供自己的用户名和密码,用户对客户端高度信任的情况下使用,比如公司、组织的内部系统,SSO。

4. Client Credentials(客户端模式):客户端服务器以自己的名义,而不是以用户的名义,向认证服务器进行认证。

下面主要讲最常用的(1)和(3)。此外,还有一个模式叫Refresh Token,也会在下面介绍。

Authorization Code(授权码模式)

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------‘      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------‘
     +---------+       (w/ Optional Refresh Token)

   Note: The lines illustrating steps (A), (B), and (C) are broken into
   two parts as they pass through the user-agent.

它的步骤如下:

(A) 用户(Resource Owner)通过用户代理(User-Agent)访问客户端(Client),客户端索要授权,并将用户导向认证服务器(Authorization Server)。

(B) 用户选择是否给予客户端授权。

(C) 假设用户给予授权,认证服务器将用户导向客户端事先指定的"重定向URI"(redirection URI),同时附上一个授权码。

(D) 客户端收到授权码,附上早先的"重定向URI",向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。

(E) 认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。这一步也对用户不可见。

Resource Owner Password(密码模式)

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

            Figure 5: Resource Owner Password Credentials Flow

它的步骤如下:

(A) 用户(Resource Owner)向客户端(Client)提供用户名和密码。

(B) 客户端将用户名和密码发给认证服务器(Authorization Server),向后者请求令牌。

(C) 认证服务器确认无误后,向客户端提供访问令牌。

令牌刷新(refresh token)

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

具体流程不再分析,我们已知,当我们申请token后,Authorization Server不仅给了我们Access Token,还有Refresh Token。当Access Token过期后,我们用Refresh Token访问/refresh端点就可以拿到新的Access Token了。

本节只讲概念,在接下来的几节中会搭建一组含有Client Application, Authorization Server, Resource Server的微服务群,并使用Eureka和Config组件管理。

原文地址:https://www.cnblogs.com/storml/p/11057244.html

时间: 2024-11-08 09:21:34

Spring Cloud(5):保护微服务 - OAuth2.0的介绍的相关文章

《Spring Cloud与Docker微服务架构实战》配套代码

不才写了本使用Spring Cloud玩转微服务架构的书,书名是<Spring Cloud与Docker微服务架构实战> - 周立,已于2017-01-12交稿.不少朋友想先看看源码,现将代码放出. 本次放出的代码: 共计70+个DEMO 覆盖Eureka.Ribbon.Feign.Hystrix.Zuul.Spring Cloud Config.Spring Cloud Bus.Spring Cloud Sleuth.Docker.Docker Compose等. 1-11章代码地址: ht

从架构到组件,深挖istio如何连接、管理和保护微服务2.0?

近几年我一直从事于微服务系统的设计以及实现方面的工作,属于微服务架构一线实践者.之前做过一些单体系统的微服务改造,在微服务拆分.治理等方面都有一定的经验. 本人比较特殊一点的经历是既做过 IT 领域的微服务,也做过 CT(通讯领域)的微服务,微服务架构在这两个领域的具体形态和要求是不太一样的,但其中一些思想是互通且是很有借鉴意义的.今天主要介绍一下关于微服务的最新发展动态,以及最近谷歌推出的 Istio平台架构. 今天介绍的主题包含:服务治理.服务网格.Istio架构,以及 Istio 相应的系

从 Spring Cloud 看一个微服务框架的「五脏六腑」

原文:https://webfe.kujiale.com/spring-could-heart/ Spring Cloud 是一个基于 Spring Boot 实现的微服务框架,它包含了实现微服务架构所需的各种组件. 注:Spring Boot 简单理解就是简化 Spring 项目的搭建.配置.组合的框架.因为与构建微服务本身没有直接关系,所以本文不对 Spring Boot 进行展开.另外本文有一些例子涉及到 Spring 和 Spring Boot,建议先了解一下 Spring 和 Spri

Spring Cloud——什么是微服务?

一.什么是微服务架构? 1.系统拆分 2.服务各自独立运行.独立部署 3.服务之间基于HTTP的Restful API通信协作 二.为什么选择Spring Cloud? 1.基于Spring Boot实现的微服务架构工具. 2.组成 Config:配置中心,支持git存储配置,实现应用配置外部化,客户端动态修改配置信息 Eureka:服务的注册与发现 Hystrix:容错管理组件,实现服务间降级和熔断 Ribbon:实现客户端负载均衡 Feign:基于Ribbon和Hystrix的声明式服务调用

实战:基于spring cloud + docker构建微服务

本系列记录学习 spring-cloud-microservice-example的实战过程,并对利用spring cloud + docker 构建端到端的微服务架构技术进行解析. 0.安装前的准备,下列软件需要安装. Maven 3 Java 8 Docker Docker Compose 我的环境 Ubuntu 16.04 Java openjdk 1.8.0 Docker 18.03.1-ce docker-compose 1.8.0 1.克隆或复制工程 $ docker clone h

Spring Cloud Alibaba 新一代微服务解决方案

本篇是「跟我学 Spring Cloud Alibaba」系列的第一篇, 每期文章会在公众号「架构进化论」进行首发更新,欢迎关注. 1.Spring Cloud Alibaba 是什么 Spring Cloud Alibaba 是阿里巴巴提供的微服务开发一站式解决方案,是阿里巴巴开源中间件与 Spring Cloud 体系的融合. 马老师左手双十一,右手阿里开源组件,不仅占据了程序员的购物车,还要攻占大家的开发工具. 先说说 Spring Cloud 提起微服务,不得不提 Spring Clou

spring cloud(一):微服务架构开篇

在公司使用spring cloud快一年了,项目也上线了,同时在线用户到达有几十万,公司之前用的是传统项目部署,业务放在一起,导致系统庞大,难以维护;采用spring cloud之后,一个业务对应一个独立的模块,也就是我们所说的微服务,开发人员维护起来就没那么困难,同时系统启动较快,下面就讲解下项目用到的技术框架: Spring Cloud是一系列框架的有序集合.它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册.配置中心.消息总线.负载均衡.断路器.数

Spring Cloud入门 (6) - 微服务与消息驱动

1.Spring Cloud Stream 介绍 Spring Cloud Stream 是一个用于构建消息驱动微服务的框架.使用Stream 框架,我们不必关心如何连接各个消息代理中间件,也不必关系如何进行消息的发送与接收,只需要简单的进行配置就可以实现这些功能. 2.消息代理中间件 Spring Cloud Stream 的绑定器提供了 RabbitMQ 与 Kafka 两个消息代理中间件的实现 3.安装 RabbitMQ 我这里直接使用 docker 安装,记得要安装 management

Spring Cloud+Docker创建微服务容器实例

1. 配置windows环境 安装windows版的docker 此步骤可自行百度一下安装方式. 配置maven环境变量 在path中添加maven的bin目录,正常情况下,maven的MAVEN_HOME已经存在了,在此基础上加/bin即为maven的path环境变量 在path中添加 在命令行中执行mvn --version,检查maven的配置是否正确 2. 配置intellij idea 打开windows版的docker,在settings窗口中勾选Expose daemon on t