1. 外卖并不好吃

  今天下班得早，想吃顿好的，于是就点了一份外卖，过了一会儿，外卖到了，但是在小区大门被堵住了，我亲自远程开门后才能进来，又过了一会，被楼下的门禁堵住了，于是我又得为其开门，拿到晚饭正准备坐下去时，突然又来了电话，出去还得确认两次，四次周折，终于吃到了我的晚饭。吃完之后，我站在阳台，望着窗外，沉思了一会儿，还是决定把这家外卖拉入我的黑名单。

  此外，我还想到了另一个问题，每次点个外卖都要这样操作，是不是有点太麻烦了，要是我能在大门确认的时候就给外卖小哥一个临时的令牌，这个令牌只能用来开楼下的门和小区的大门，除此之外没有其他功能，并且几分钟后就过期没用了，这样的话我省下的时间至少可以多抠两次脚。
  然而现实并没有这么好的事情，小区不提供这样的操作。但是这个想法却让我想到了一种协议——oauth2.0，我拉完肚子之后想了一想，上面说的这种方式不就是oauth2.0中最常用的授权码方式吗，通过给临时令牌的方式来让第三方应用访问特定权限的资源。小区不提供这种操作， 但是互联网可以。

2.Oauth2.0协议

  直接说oauth2.0你可能觉得很陌生，但是下面这张图，你一定见过。

  熟悉吧，这是微信上的小程序，这种用的就是授权码的方式了，那么这种方式的具体流程是咋样的呢？很简单。

  就这样，oauth2.0就这样结束了。可能有人会说："诶，你上面这么多个字看了也全忘光了，就不能整张图出来嘛？"

  okay，诺，这是你要的图：

  这张图应该能很清晰的描述整个过程，那么为什么要整得这么复杂呢，整这么多花里胡哨的，简单点不好吗？不好！简单点，我们可能就看不到微信了。我们先来看如果不这么做的话会是怎么样的。

  你看，这种方式就会损失很多暴躁的用户，所以为了用（zhuan）户（geng）更（duo）方（de）便（qian），必须自己先把麻烦的事情给做了，才能让用户满意。
  退一万步讲，就算用户足够耐心，接受输入账号密码，但是还有一个人肯定不同意，那就是微信，为啥呢？如果微信用户的数据第三方都能知道，那么微信再见，因此微信肯定不会同意让数据泄露的，所以使用oauth2.0=win-win。
  最后oauth2.0还有其他几种方式：隐藏式、密码式和凭证式。前两个是针对没有后端直接将令牌给前端用的，凭证式的话就是本章的方式中去掉了授权码的形式，这种形式主要是针对应用的。就是说，这个应用可以拿到不止一个用户的数据，而且不需要用户同意。有兴趣的话深入的话可以自己去了解一下，不过除了凭证式另外两个基本都很少用。