從一次外賣到對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！