Oauth2.0认证模式

背景

首先token认证方式的出现是伴随着系统架构的发展而来的。

最初的单机应用使用sessionId+cookie完全可以满足问题。

随着系统业务访问量加大，为满足服务高可用需求，系统引入了分布式架构，但是session只能存在单机节点上，为了解决这一问题，首先使用过 session粘贴 技术（通过hash等手段让请求始终访问之前生成sessionId的节点），这个方案的问题是万一存sessionId的节点挂了，整个系统都不能登陆了，也违背了高可用的设计思路；后来使用 session复制 的方案，即每台节点都copy一份sessionId，这引出2个问题，第一个就是分布式一致性的问题，节点同一时间重复创建了怎么办？另一个就是更头疼的系统扩展问题，随着系统越来越庞大，节点增多，session复制消耗的性能也越来越大，整个系统因为session出现了可遇见的性能瓶颈；再后来出现了session集中存储到一个地方，这样解放了服务器，但是session存储的高可用问题又来了，简直就是套娃式困局。

既然 有状态服务 出现瓶颈，大佬们开始提出 无状态服务 ，就是使用token验证方式替代较重的session，token就是一个字符串，只要服务根据约定好的算法解析出的结果跟预期一致就可以通过验证，也不需要保存在内存中，无状态服务的好处是系统扩展轻松，新追加的服务轻装上阵，完全没有顾虑。Oauth就是一种规范，用来保证token机制的可行，目前在web端和移动端都是主流登陆验证方案，Oauth20于2010年正式提出，一直沿用到现在，可见其稳定。

随着互联网行业迅猛发展，各种app，各种网站层出不穷，传统登陆方式就要求用户在每个想登陆的站点都要注册自己的账号信息和密码，这也留下了一定隐患，有的小站点可能技术不那么强，这就有可能导致用户信息泄漏，Oauth正好可以解决这种对一些站点即想用又不信任问题。从使用体验的角度，单点登陆的方式也可以简化用户对账号密码的管理。

Oauth2认证模式的4种类型

这种模式最常用，也是最安全的模式，相关的角色有3个：

客户端 （web站点/app，从认证服务的视角，不管你是web页面还是后台服务，都属于客户端范畴）、 资源服务 （存放个人信息的服务，比如微信存放你个人信息的服务）、 认证服务 （某可信的账户平台如微信平台）

使用之前需要在认证服务注册下自己的app信息（主要包括app名称、app站点、认证callback地址等），认证平台会给客户端创建一个clientId（客户端id）和client_secret（客户端秘钥）。这是为了解决认证平台不信任客户端的问题。

使用的时候用户首先会点击客户端登陆页上的一个链接，打开认证服务上的一个登陆确认页面，用户认证的时候会上传以下请求参数：

认证成功后，认证服务会重定向到redirect_uri,

同时认证服务还会按照之前注册好的callback地址，向客户端发一个get请求，参数：

这样客户端拿到了code，会再向认证平台的授权服务器发起请求，参数：

授权服务验证code没问题后，会给客户端返回token。

客户端拿着token就可以去资源服务器请求用户信息了（头像、姓名等）。

这种模式大致流程是：

这个模式不经过code验证的过程，这种token可以直接在callback的uri上看到，并且客户端后台也不会验证token，这种模式安全性显然没有授权码模式好，应用也不多。

流程：

用户直接在客户端上输入账号密码，然后由客户端向认证服务请求要token。

要使用这种模式就表明用户完全信任客户端了，如果信任客户端，直接在客户端上注册账号不就好了，何必把其他平台的账号告诉客户端，万一客户端保存了这个账号密码呢？

流程：

用客户端自己的名义向认证服务获取token，跟用户没什么关系。这也不会是登陆会考虑的场景吧

http://wwwruanyifengcom/blog/2019/04/oauth-grant-typeshtml

https://wwwbilibilicom/video/BV1zt41127hXspm_id_from=33399900

目前还没有证书服务器的说法，您这边应该是想表示SSL证书的作用是什么吧。

什么是 SSL 证书

SSL 全称为“Secure Sockets Layer”，中文译为“安全套接层”，是遵守 SSL 安全套接层协议的数字证书，为网络通信提供安全及数据完整性的一种安全协议。

安全套接层，顾名思义是在 TCP 上提供的安全套接字层。其位于应用层和传输层之间，应用层数据不再直接传递给传输层而是传递给 SSL 层，SSL 层对从应用层收到的数据进行加密，利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。HTTPS 便是指 Hyper Text Transfer Protocol over SecureSocket Layer。

SSL证书的作用分析：

1、网站实现加密传输，加强隐私安全保护

网站没安装SSL证书的话，是以http协议来访问的，浏览器和服务器之间是明文传输，这意味着用户填写的账户信息、交易记录等隐私信息都是明文，存在被泄露、窃取及篡改的风险，容易被恶意攻击，给用户带来损失。

2、认证服务器真实身份，防止钓鱼网站仿冒

网站部署全球信任的SSL证书后，浏览器内置安全机制，实时查验证书状态，通过浏览器向用户展示网站认证信息，让用户轻松识别网站真实身份，防止钓鱼网站仿冒。

3、有利于提高网站搜索排名及收录

现在各个主流浏览器会优先收录以https开头的网站，即安装了SSL证书的网站，例如百度、谷歌等浏览器对https网站比较友好，搜索排名及收录往往会比较不错，但如果是没有安装SSL证书的网站，就会提示安全风险警告信息，给访问者带来不好的体验。

4、提高公司品牌形象和可信度

SSL证书有多种类型，按照验证等级不同，从低到高，主要分为域名型DV SSL证书、企业型OV SSL证书、增强型EV SSL证书。安装了OV SSL证书或EV SSL证书的网站，访问者可以在浏览器地址栏查看到公司名称，另外EV证书会直接显示https绿色安全锁图标，用户可直观地了解到其访问的是安全可信的站点，可放心的进行操作和交易，有效提升公司的品牌形象和可信度。

J2EE Java2平台企业版（Java 2 Platform,Enterprise Edition）

J2EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。

J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，导致企业内部或外部难以互通的窘境。

在J2EE架构下，开发人员可依循规范基础，进而开发企业级应用；而不同J2EE供货商，同会支持不同J2EE版本内所拟定的标准，以确保不同J2EE平台与产品之间的兼容性。换言之，植基J2EE架构的应用系统，基本上可部署在不同的应用服务器之上，无需或者只须要进行少量的代码修改，即能大幅提高应用系统的可移植性(Portability)。

J2EE主由升阳(SUN)与IBM等厂商协同业界共同拟定而成的技术规范，以企业与企业之间的运算为导向的JAVA开发环境。J2EE架构定义各类不同组件，如Web Component、EJB Component…等，而各类组件可以再用(reuse)，让已开发完成的组件，或者是经由市面采购而得的组件，均能进一步组装成不同的系统。

对于开发人员而言，只需要专注于各种应用系统的商业逻辑与架构设计，至于底层繁琐的程序撰写工作，可搭配不同的开发平台，以让应用系统的开发与部署效率大幅提升。

J2EE的核心规范是 Enterprise Java Beans（EJBs）。EJB依照特性的不同，目前共分为三种，分别是Session Bean、Entity Bean，以及 Message Driven Bean 。其中 Session Bean 与Entity Bean 算是EJB的始祖，这两种EJB规格在EJB 1x版本推出时就已经存在，而Message Driven Bean则是出现在EJB 20的规格之中。

目前业界许多程序设计师，或者是网页设计人员，多利用JSP/Servlet的便利性，进而在J2EE服务器之上开发相关的应用，或是整合公司内部的各种资源。

Java 2平台依照应用领域的不同，共分为三大版本，分别是J2EE、标准版本J2SE（Java 2 Platform, Standard Edition）、微型版本J2ME（Java 2 Platform, Micro Edition），以及Java Card等。

从整体上讲，J2EE是使用Java技术开发企业级应用的一种事实上的工业标准(Sun公司出于其自身利益的考虑，至今没有将Java及其相关技术纳入标准化组织的体系)，它是Java技术不断适应和促进企业级应用过程中的产物。Sun推出J2EE的目的是为了克服传统Client/Server模式的弊病，迎合Browser/Server架构的潮流，为应用Java技术开发服务器端应用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业级平台，从而简化企业应用的开发、管理和部署。J2EE是一个标准，而不是一个现成的产品。各个平台开发商按照J2EE规范分别开发了不同的J2EE应用服务器，J2EE应用服务器是J2EE企业级应用的部署平台。由于它们都遵循了J2EE规范，因此，使用J2EE技术开发的企业级应用可以部署在各种J2EE应用服务器上。

为了推广并规范化使用J2EE架构企业级应用的体系架构，Sun同时给出了一个建议性的J2EE应用设计模型：J2EE Blueprints。J2EE Blueprints提供了实施J2EE企业级应用的体系架构、设计模式和相关的代码，通过应用J2EE Blueprints所描述的体系模型，能够部分简化架构企业级应用这项复杂的工作。J2EE Blueprints是开发人员设计和优化J2EE组件的基本原则，同时为围绕开发工作进行职能分工给出了指导性策略，以帮助应用开发设计人员合理地分配技术资源。

J2EE组成了一个完整企业级应用的不同部分纳入不同的容器(Container)，每个容器中都包含若干组件(这些组件是需要部署在相应容器中的)，同时各种组件都能使用各种J2EE Service/API。J2EE容器包括：

◆ Web容器 服务器端容器，包括两种组件JSP和Servlet，JSP和Servlet都是Web服务器的功能扩展，接受Web请求，返回动态的Web页面。Web容器中的组件可使用EJB容器中的组件完成复杂的商务逻辑。

◆ EJB容器 服务器端容器，包含的组件为EJB(Enterprise JavaBeans)，它是J2EE的核心之一，主要用于服务器端的商业逻辑的实现。EJB规范定义了一个开发和部署分布式商业逻辑的框架，以简化企业级应用的开发，使其较容易地具备可伸缩性、可移植性、分布式事务处理、多用户和安全性等。

◆ Applet容器 客户端容器，包含的组件为Applet。Applet是嵌在浏览器中的一种轻量级客户端，一般而言，仅当使用Web页面无法充分地表现数据或应用界面的时候，才使用它。Applet是一种替代Web页面的手段，我们仅能够使用J2SE开发Applet，Applet无法使用J2EE的各种Service和API，这是为了安全性的考虑。

◆ Application Client容器 客户端容器，包含的组件为Application Client。Application Client相对Applet而言是一种较重量级的客户端，它能够使用J2EE的大多数Service和API。

通过这四个容器，J2EE能够灵活地实现前面描述的企业级应用的架构。

在View部分，J2EE提供了三种手段：Web容器中的JSP(或Servlet)、Applet和Application Client，分别能够实现面向浏览器的数据表现和面向桌面应用的数据表现。Web容器中的Servlet是实现Controller部分业务流程控制的主要手段；而EJB则主要针对Model部分的业务逻辑实现。至于与各种企业资源和企业级应用相连接，则是依靠J2EE的各种服务和API。

在J2EE的各种服务和API中，JDBC和JCA用于企业资源(各种企业信息系统和数据库等)的连接，JAX-RPC、JAXR和SAAJ则是实现Web Services和Web Services连接的基本支持。

J2EE的各种组件

我们就J2EE的各种组件、服务和API，进行更加详细的阐述，看看在开发不同类型的企业级应用时，根据各自需求和目标的不同，应当如何灵活使用并组合不同的组件和服务。

· Servlet

Servlet是Java平台上的CGI技术。Servlet在服务器端运行，动态地生成Web页面。与传统的CGI和许多其它类似CGI的技术相比，Java Servlet具有更高的效率并更容易使用。对于Servlet，重复的请求不会导致同一程序的多次转载，它是依靠线程的方式来支持并发访问的。

· JSP

JSP(Java Server Page)是一种实现普通静态HTML和动态页面输出混合编码的技术。从这一点来看，非常类似Microsoft ASP、PHP等技术。借助形式上的内容和外观表现的分离，Web页面制作的任务可以比较方便地划分给页面设计人员和程序员，并方便地通过JSP来合成。在运行时态，JSP将会被首先转换成Servlet，并以Servlet的形态编译运行，因此它的效率和功能与Servlet相比没有差别，一样具有很高的效率。

· EJB

EJB定义了一组可重用的组件：Enterprise Beans。开发人员可以利用这些组件，像搭积木一样建立分布式应用。在装配组件时，所有的Enterprise Beans都需要配置到EJB服务器(一般的Weblogic、WebSphere等J2EE应用服务器都是EJB服务器)中。EJB服务器作为容器和低层平台的桥梁管理着EJB容器，并向该容器提供访问系统服务的能力。所有的EJB实例都运行在EJB容器中。EJB容器提供了系统级的服务，控制了EJB的生命周期。EJB容器为它的开发人员代管了诸如安全性、远程连接、生命周期管理及事务管理等技术环节，简化了商业逻辑的开发。EJB中定义了三种Enterprise Beans：

◆ Session Beans

◆ Entity Beans

◆ Message-driven Beans

· JDBC

JDBC(Java Database Connectivity，Java数据库连接)API是一个标准SQL(Structured Query Language，结构化查询语言)数据库访问接口，它使数据库开发人员能够用标准Java API编写数据库应用程序。JDBC API主要用来连接数据库和直接调用SQL命令执行各种SQL语句。利用JDBC API可以执行一般的SQL语句、动态SQL语句及带IN和OUT参数的存储过程。Java中的JDBC相当与Microsoft平台中的ODBC(Open Database Connectivity)。

· JMS

JMS(Java Message Service，Java消息服务)是一组Java应用接口，它提供创建、发送、接收、读取消息的服务。JMS API定义了一组公共的应用程序接口和相应语法，使得Java应用能够和各种消息中间件进行通信，这些消息中间件包括IBM MQ-Series、Microsoft MSMQ及纯Java的SonicMQ。通过使用JMS API，开发人员无需掌握不同消息产品的使用方法，也可以使用统一的JMS API来操纵各种消息中间件。通过使用JMS，能够最大限度地提升消息应用的可移植性。 JMS既支持点对点的消息通信，也支持发布/订阅式的消息通信。

· JNDI

由于J2EE应用程序组件一般分布在不同的机器上，所以需要一种机制以便于组件客户使用者查找和引用组件及资源。在J2EE体系中，使用JNDI(Java Naming and Directory Interface)定位各种对象，这些对象包括EJB、数据库驱动、JDBC数据源及消息连接等。JNDI API为应用程序提供了一个统一的接口来完成标准的目录操作，如通过对象属性来查找和定位该对象。由于JNDI是独立于目录协议的，应用还可以使用JNDI访问各种特定的目录服务，如LDAP、NDS和DNS等。

· JTA

JTA(Java Transaction API)提供了J2EE中处理事务的标准接口，它支持事务的开始、回滚和提交。同时在一般的J2EE平台上，总提供一个JTS(Java Transaction Service)作为标准的事务处理服务，开发人员可以使用JTA来使用JTS。

· JCA

JCA(J2EE Connector Architecture)是J2EE体系架构的一部分，为开发人员提供了一套连接各种企业信息系统(EIS，包括ERP、SCM、CRM等)的体系架构，对于EIS开发商而言，它们只需要开发一套基于JCA的EIS连接适配器，开发人员就能够在任何的J2EE应用服务器中连接并使用它。基于JCA的连接适配器的实现，需要涉及J2EE中的事务管理、安全管理及连接管理等服务组件。

· JMX

JMX(Java Management Extensions)的前身是JMAPI。JMX致力于解决分布式系统管理的问题。JMX是一种应用编程接口、可扩展对象和方法的集合体，可以跨越各种异构操作系统平台、系统体系结构和网络传输协议，开发无缝集成的面向系统、网络和服务的管理应用。JMX是一个完整的网络管理应用程序开发环境，它同时提供了厂商需要收集的完整的特性清单、可生成资源清单表格、图形化的用户接口；访问SNMP的网络API；主机间远程过程调用；数据库访问方法等。

· JAAS

JAAS(Java Authentication and Authorization Service)实现了一个Java版本的标准Pluggable Authentication Module(PAM)的框架。JAAS可用来进行用户身份的鉴定，从而能够可靠并安全地确定谁在执行Java代码。同时JAAS还能通过对用户进行授权，实现基于用户的访问控制。

· JACC

JACC(Java Authorization Service Provider Contract for Containers)在J2EE应用服务器和特定的授权认证服务器之间定义了一个连接的协约，以便将各种授权认证服务器插入到J2EE产品中去。

· JAX-RPC

通过使用JAX-RPC(Java API for XML-based RPC)，已有的Java类或Java应用都能够被重新包装，并以Web Services的形式发布。JAX-RPC提供了将RPC参数(in/out)编码和解码的API，使开发人员可以方便地使用SOAP消息来完成RPC调用。同样，对于那些使用EJB(Enterprise JavaBeans)的商业应用而言，同样可以使用JAX-RPC来包装成Web服务，而这个Web Servoce的WSDL界面是与原先的EJB的方法是对应一致的。JAX-RPC为用户包装了Web服务的部署和实现，对Web服务的开发人员而言，SOAP/WSDL变得透明，这有利于加速Web服务的开发周期。

· JAXR

JAXR（Java API for XML Registries）提供了与多种类型注册服务进行交互的API。JAXR运行客户端访问与JAXR规范相兼容的Web Servcices，这里的Web Services即为注册服务。一般来说，注册服务总是以Web Services的形式运行的。JAXR支持三种注册服务类型：JAXR Pluggable Provider、Registry-specific JAXR Provider、JAXR Bridge Provider(支持UDDI Registry和ebXML Registry/Repository等)。

· SAAJ

SAAJ(SOAP with Attachemnts API for Java)是JAX-RPC的一个增强，为进行低层次的SOAP消息操纵提供了支持。

企业级应用示例

下面我们通过假设一个企业应用的J2EE实现，来了解各种组件和服务的应用。假设应用对象是计算机产品的生产商/零售商的销售系统，这个销售系统能够通过自己的网站发布产品信息，同时也能将产品目录传送给计算机产品交易市场。销售系统能够在线接受订单(来自自己的Web网站或者来自计算机产品交易市场)，并随后转入内部企业管理系统进行相关的后续处理。

参见图3，这个企业应用可以这种方式架构。该企业应用的核心是产品目录管理和产品定购管理这两个业务逻辑，使用EJB加以实现，并部署在EJB容器中。由于产品目录和定购信息都需要持久化，因此使用JDBC连接数据库，并使用JTA来完成数据库存取事务。

图3 J2EE应用示例

然后使用JSP/Servlet来实现应用的Web表现：在线产品目录浏览和在线定购。为了将产品目录发送给特定的交易市场，使用JMS实现异步的基于消息的产品目录传输。为了使得更多的其它外部交易市场能够集成产品目录和定购业务，需要使用Web Services技术包装商业逻辑的实现。由于产品定购管理需要由公司内部雇员进行处理，因此需要集成公司内部的用户系统和访问控制服务以方便雇员的使用，使用JACC集成内部的访问控制服务，使用JNDI集成内部的用户目录，并使用JAAS进行访问控制。由于产品订购事务会触发后续的企业ERP系统的相关操作(包括仓储、财务、生产等)，需要使用JCA连接企业ERP。

最后为了将这个应用纳入到企业整体的系统管理体系中去，使用Application Client架构了一个管理客户端(与其它企业应用管理应用部署在一台机器上)，并通过JMX管理这个企业应用。