从一次外卖到对oauth2.0的思考

别问oauth1.0哪去了，问就是很差讲。

1. 外卖并很差吃

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

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

2.Oauth2.0协议

  直接说oauth2.0你可能以为很陌生，可是下面这张图，你必定见过。

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

1. 第三方（小程序）在受权服务（微信）上提早进行登记，这是前期工做，拿到属于本身的标识，以后请求的时候须要带上这个标识来代表本身的身份。
2. 第三方想要用户资源的时候首先要先拿到受权码，再经过受权码和上面的身份ID拿到属于本身的临时令牌，可是受权服务直接给的话可能会被用户投诉，因此就把这个赞成操做交给用户本身处理，因而就弹出了上面这个框。
3. 用户赞成以后，受权服务生成受权码，记录对应的信息，接着返回给第三方。
4. 第三方拿到受权码以后就能够向受权服务申请临时令牌了，受权服务校验经过以后生成令牌并设置权限范围，而后返回。
5. 以外第三方若是想要从受权服务这边获取用户的信息就得带上这个令牌和本身的身份ID，经过校验而且在权限范围内则返回。

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

  okay，诺，这是你要的图：

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

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

本文为博客园文章，点此跳转

nope！nope！nope！