別問oauth1.0哪去了，問就是不好講。
1. 外賣並不好吃
今天下班得早，想吃頓好的，於是就點了一份外賣，過了一會兒，外賣到了，但是在小區大門被堵住了，我親自遠程開門后才能進來，又過了一會，被樓下的門禁堵住了，於是我又得為其開門，拿到晚飯正准備坐下去時，突然又來了電話，出去還得確認兩次，四次周折，終於吃到了我的晚飯。吃完之后，我站在陽台，望着窗外，沉思了一會兒，還是決定把這家外賣拉入我的黑名單。
此外，我還想到了另一個問題，每次點個外賣都要這樣操作，是不是有點太麻煩了，要是我能在大門確認的時候就給外賣小哥一個臨時的令牌，這個令牌只能用來開樓下的門和小區的大門，除此之外沒有其他功能，並且幾分鍾后就過期沒用了，這樣的話我省下的時間至少可以多摳兩次腳。
然而現實並沒有這么好的事情，小區不提供這樣的操作。但是這個想法卻讓我想到了一種協議——oauth2.0，我拉完肚子之后想了一想，上面說的這種方式不就是oauth2.0中最常用的授權碼方式嗎，通過給臨時令牌的方式來讓第三方應用訪問特定權限的資源。小區不提供這種操作， 但是互聯網可以。
2.Oauth2.0協議
直接說oauth2.0你可能覺得很陌生，但是下面這張圖，你一定見過。
熟悉吧，這是微信上的小程序，這種用的就是授權碼的方式了，那么這種方式的具體流程是咋樣的呢？很簡單。
- 第三方（小程序）在授權服務（微信）上提前進行登記，這是前期工作，拿到屬於自己的標識，之后請求的時候需要帶上這個標識來表明自己的身份。
- 第三方想要用戶資源的時候首先要先拿到授權碼，再通過授權碼和上面的身份ID拿到屬於自己的臨時令牌，但是授權服務直接給的話可能會被用戶投訴，所以就把這個同意操作交給用戶自己處理，於是就彈出了上面這個框。
- 用戶同意之后，授權服務生成授權碼，記錄對應的信息，接着返回給第三方。
- 第三方拿到授權碼之后就可以向授權服務申請臨時令牌了，授權服務校驗通過之后生成令牌並設置權限范圍，然后返回。
- 之外第三方如果想要從授權服務這邊獲取用戶的信息就得帶上這個令牌和自己的身份ID，通過校驗並且在權限范圍內則返回。
就這樣，oauth2.0就這樣結束了。可能有人會說："誒，你上面這么多個字看了也全忘光了，就不能整張圖出來嘛？"
okay，諾，這是你要的圖：
這張圖應該能很清晰的描述整個過程，那么為什么要整得這么復雜呢，整這么多花里胡哨的，簡單點不好嗎？不好！簡單點，我們可能就看不到微信了。我們先來看如果不這么做的話會是怎么樣的。
你看，這種方式就會損失很多暴躁的用戶，所以為了用（zhuan）戶（geng）更（duo）方（de）便（qian），必須自己先把麻煩的事情給做了，才能讓用戶滿意。
退一萬步講，就算用戶足夠耐心，接受輸入賬號密碼，但是還有一個人肯定不同意，那就是微信，為啥呢？如果微信用戶的數據第三方都能知道，那么微信再見，因此微信肯定不會同意讓數據泄露的，所以使用oauth2.0=win-win。
最后oauth2.0還有其他幾種方式：隱藏式、密碼式和憑證式。前兩個是針對沒有后端直接將令牌給前端用的，憑證式的話就是本章的方式中去掉了授權碼的形式，這種形式主要是針對應用的。就是說，這個應用可以拿到不止一個用戶的數據，而且不需要用戶同意。有興趣的話深入的話可以自己去了解一下，不過除了憑證式另外兩個基本都很少用。
nope！nope！nope！