OAuth 2.0 极简教程 （The OAuth 2.0 Authorization Framework）

OAuth 2.0 是什么？

OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容，OAuth2.0 不兼容OAuth 1.0 。

简单讲，这是一种授权机制。数据的所有者（Resource Owner）告诉系统，同意授权第三方应用（third party Application）进入系统（Server），获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

在传统的客户端-服务器身份验证模型中，客户端通过使用向服务器进行身份验证证书，进而向服务器请求受保护的资源 。

为了提供第三方应用程序访问这些资源，资源需要把用户名密码等认证信息共享给第三方。这会带来一些问题和局限性：

o 需要第三方应用程序来存储资源所有者的凭证供将来使用，通常是密码明文。

o 要求服务器支持密码验证密码固有的安全性弱点。

o 第三方应用程序获得了对资源的广泛访问。从而使资源所有者没有任何
限制持续时间或访问有限子集的能力。

o 资源所有者不能撤消对单个第三方的访问权限。如果必须这样做，就得更改第三方的密码。那这样就会影响所有的授权第三方。

OAuth通过引入授权层解决了这些问题。

在OAuth中，客户端请求访问受控资源由资源所有者并由资源服务器托管，并且发行了与资源不同的一组凭证——访问令牌，它由授权服务器向第三方客户端颁发，由给资源所有者批准通过。客户端获得访问令牌（表示字符串的字符串：具体范围，生存期和其他访问属性等），用它来访问资源服务器托管的受保护资源。

OAuth2中有四个领域模型（角色，Roles）：

• Resource Owner：资源所有者 即上述中的微信用户

• Resource Server：资源服务器 即上述中的微信服务器，提供微信用户基本信息给到第三方应用

• Client：第三方应用客户端 即上述中你公司正在开发的第三方应用

• Authorication Server：授权服务器 该角色可以理解为管理其余三者关系的中间层

不难看出，OAuht2 解决问题的关键在于使用授权服务器提供一个访问凭据给到第三方应用，让第三方应用可以在不知道资源所有者在资源服务器上的账号和密码的情况下，能获取到资源所有者在资源服务器上的受保护资源，这里的受保护资源就是微信用户的姓名以及头像等信息。

OAuth 2.0 问题场景

为了理解OAuth的适用场合，让我举一个假设的例子。

有一个"云冲印"的网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取自己储存在Google上的照片。

云冲印

问题是只有得到用户的授权，Google才会同意"云冲印"读取这些照片。

那么，"云冲印"怎样获得用户的授权呢？

传统方法是，用户将自己的Google用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。

（1）"云冲印"为了后续的服务，会保存用户的密码，这样很不安全。
（2）Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。
（3）"云冲印"拥有了获取用户储存在Google所有资料的权力，用户没法限制"云冲印"获得授权的范围和有效期。
（4）用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。
（5）只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的。

问题解决思路

计算机中的所有问题都可以通过添加一个中间层来解决。

OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

名词解释

在详细讲解OAuth 2.0之前，需要了解几个专用名词。它们对读懂后面的讲解，尤其是几张图，至关重要。

（1） Third-party application：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"云冲印"。

（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Google。

（3）Resource Owner：资源所有者，本文中又称"用户"（user）。

（4）User Agent：用户代理，本文中就是指浏览器。

（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。

（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

知道了上面这些名词，就不难理解，OAuth的作用就是让"客户端"安全可控地获取"用户"的授权，与"服务商提供商"进行互动。

OAuth 2.0 协议的运行流程（Protocol Flow）

OAuth 2.0的运行流程如下图，摘自RFC 6749。（http://www.rfcreader.com/#rfc6749）

The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
interaction between the four roles and includes the following steps:

(A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.

(B) The client receives an authorization grant, which is a credential representing the resource owner's authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server. An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types -- authorization code, implicit, resource owner password credentials, and client credentials -- as well as an extensibility mechanism for defining additional types.

(C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant.

(D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.

(E) The client requests the protected resource from the resource server and authenticates by presenting the access token.

(F) The resource server validates the access token, and if valid, serves the request.

实例讲解

第三方应用授权登录：在APP或者网页接入一些第三方应用时，时长会需要用户登录另一个合作平台，比如QQ，微博，微信的授权登录。

原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、请求后台数据。

前后端分离单页面应用（spa）：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证，比如使用vue、react后者h5开发的app。

客户端的授权模式
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式:

授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
客户端模式（client credentials）
四种授权模式

授权码模式

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。

（1）用户访问客户端，后者将前者导向认证服务器，假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（2）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌：GET /oauth/token?response_type=code&client_id=test&redirect_uri=重定向页面链接。请求成功返回code授权码，一般有效时间是10分钟。

（3）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向页面链接。请求成功返回access Token和refresh Token。

下面是上面这些步骤所需要的参数。

A步骤中，客户端申请认证的URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为"code"

• client_id：表示客户端的ID，必选项

• redirect_uri：表示重定向URI，可选项

• scope：表示申请的权限范围，可选项

• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

下面是一个例子。

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

C步骤中，服务器回应客户端的URI，包含以下参数：

• code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。

• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

下面是一个例子。

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：

• grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。

• code：表示上一步获得的授权码，必选项。

• redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。

• client_id：表示客户端ID，必选项。

下面是一个例子。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
 
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

E步骤中，认证服务器发送的HTTP回复，包含以下参数：

• access_token：表示访问令牌，必选项。

• token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。

• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。

• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。

• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

下面是一个例子。

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

从上面代码可以看到，相关参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存。

参考资料

https://oauth.net/2/
The OAuth 2.0 Authorization Framework：
http://www.rfcreader.com/#rfc6749
https://tools.ietf.org/html/rfc6749
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
https://developers.google.com/identity/protocols/oauth2

---

Kotlin开发者社区

专注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函数式编程、编程思想、"高可用，高性能，高实时"大型分布式系统架构设计主题。

High availability, high performance, high real-time large-scale distributed system architecture design。

分布式框架：Zookeeper、分布式中间件框架等
分布式存储：GridFS、FastDFS、TFS、MemCache、redis等
分布式数据库：Cobar、tddl、Amoeba、Mycat
云计算、大数据、AI算法
虚拟化、云原生技术
分布式计算框架：MapReduce、Hadoop、Storm、Flink等
分布式通信机制：Dubbo、RPC调用、共享远程数据、消息队列等
消息队列MQ：Kafka、MetaQ，RocketMQ
怎样打造高可用系统：基于硬件、软件中间件、系统架构等一些典型方案的实现：HAProxy、基于Corosync+Pacemaker的高可用集群套件中间件系统
Mycat架构分布式演进
大数据Join背后的难题：数据、网络、内存和计算能力的矛盾和调和
Java分布式系统中的高性能难题：AIO，NIO，Netty还是自己开发框架？
高性能事件派发机制：线程池模型、Disruptor模型等等。。。

合抱之木，生于毫末；九层之台，起于垒土；千里之行，始于足下。不积跬步，无以至千里；不积小流，无以成江河。

Kotlin 简介

Kotlin是一门非研究性的语言，它是一门非常务实的工业级编程语言，它的使命就是帮助程序员们解决实际工程实践中的问题。使用Kotlin 让 Java程序员们的生活变得更好，Java中的那些空指针错误，浪费时间的冗长的样板代码，啰嗦的语法限制等等，在Kotlin中统统消失。Kotlin 简单务实，语法简洁而强大，安全且表达力强，极富生产力。

Java诞生于1995年，至今已有23年历史。当前最新版本是 Java 9。在 JVM 生态不断发展繁荣的过程中，也诞生了Scala、Groovy、Clojure 等兄弟语言。

Kotlin 也正是 JVM 家族中的优秀一员。Kotlin是一种现代语言（版本1.0于2016年2月发布）。它最初的目的是像Scala那样，优化Java语言的缺陷，提供更加简单实用的编程语言特性，并且解决了性能上的问题，比如编译时间。JetBrains在这些方面做得非常出色。

Kotlin语言的特性

用 Java 开发多年以后，能够尝试一些新的东西真是太棒了。如果您是 Java 开发人员，使用 Kotlin 将会非常自然流畅。如果你是一个Swift开发者，你将会感到似曾相识，比如可空性（Nullability）。Kotlin语言的特性有：

1.简洁

大幅减少样板代码量。

2.与Java的100%互操作性

Kotlin可以直接与Java类交互，反之亦然。这个特性使得我们可以直接重用我们的代码库，并将其迁移到 Kotlin中。由于Java的互操作性几乎无处不在。我们可以直接访问平台API以及现有的代码库，同时仍然享受和使用 Kotlin 的所有强大的现代语言功能。

3.扩展函数

Kotlin 类似于 C# 和 Gosu, 它提供了为现有类提供新功能扩展的能力，而不必从该类继承或使用任何类型的设计模式 (如装饰器模式)。

4.函数式编程

Kotlin 语言一等支持函数式编程，就像Scala一样。具备高阶函数、Lambda 表达式等函数式基本特性。

5.默认和命名参数

在Kotlin中，您可以为函数中的参数设置一个默认值，并给每个参数一个名称。这有助于编写易读的代码。

6.强大的开发工具支持

而由于是JetBrains出品，我们拥有很棒的IDE支持。虽然Java到Kotlin的自动转换并不是100% OK 的，但它确实是一个非常好的工具。使用 IDEA 的工具转换Java代码为 Kotlin 代码时，可以轻松地重用60％-70％的结果代码，而且修改成本很小。

Kotlin 除了简洁强大的语法特性外，还有实用性非常强的API以及围绕它构建的生态系统。例如：集合类 API、IO 扩展类、反射API 等。同时 Kotlin 社区也提供了丰富的文档和大量的学习资料，还有在线REPL。

A modern programming language that makes developers happier. Open source forever

图来自《Kotlin从入门到进阶实战》 (陈光剑，清华大学出版社)

图来自《Kotlin从入门到进阶实战》 (陈光剑，清华大学出版社)

https://kotlinlang.org/