別問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！