从一次外卖到对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！