Laravel Passport裏的受權類型介紹

本文來自pilishen.com---- 原文連接; 歡迎來和pilishen一塊兒學習php&Laravel；學習羣：109256050

OAuth2是一個安全框架，控制着程序受保護部分的准入，主要是控制不一樣的客戶端如何來調取API，保證它們在請求相應資源的時候有相應的權限。

Laravel Passport是一個強大的Oauth2服務實現，使用Passport每每已經足以應對咱們平常API開發中的各類需求，甚至說，大部分時候，咱們只是用到了Passport的部分功能而已。也正由於其強大，因此理解和使用起來也有必定難度，而這其中，理解和熟悉oauth2相關的各類受權類型是關鍵，受權類型理解了，Passport也就沒什麼難的了。話很少說，一塊兒來看看不一樣的受權類型都是怎麼回事吧。

概念理解：

1. 客戶端（Client）

指的是調取你程序API的那個應用，或者說終端，在Passport裏建立客戶端能夠經過artisan命令來進行

php artisan passport:client

每個客戶端（client）都要有一個key, name, secret, redirect URI, user（程序建立者/全部者）

2. 資源擁有者（Resource Owner）

這個指的是客戶端請求的那個API，其背後所對應資源（或者說數據）的全部者（user）

3. 資源服務器（Resource Server）

這個也就是咱們的API，能夠是不須要讀取權限的公共數據，也能夠是須要驗證權限的私有數據。公共數據，或者說公開節點（endpoints），舉個例子就是好比說搜索全部的tweets消息，或者說搜索微信文章，這不須要特別的權限，誰均可以搜。另外一方面，假設說以某個用戶的名義去發佈（post）一個推特消息，發一個朋友圈，就須要來自這個用戶的權限認證了。

4. 權限範圍（Scope）

指的是獲取特定數據，或者進行特定操做的權限（permission），能夠在AuthServiceProvider使用Passport::tokensCan()方法來具體定義權限（scope）

Passport::tokensCan([
    'read-tweets' => 'Read all tweets',
    'post-tweet' => 'Post new tweet',
]);

5. 准入令牌（Access token）

當客戶端程序想要取得某些受保護的數據時，就要傳遞一個准入令牌（Access token），以此來驗證當前請求（request）。

受權類型（Grant Type）

受權（Grant），說白了就是從資源服務器獲取准入令牌（Access token）的方式，也能夠更通俗地說成頒發令牌（token）的方式。一共有五種受權方式，其中四種是用來獲取令牌（Access token）的，另外一個是用來刷新、或者說從新建立一個已有令牌（token）的。

1. 認證碼受權（Authorization Code grant）

這是最多見的一種類型，說白了就是第三方登錄，也即當第三方的程序想着獲取咱們這邊的受保護信息，這個第三方程序必須得得到咱們這邊用戶的認證受權。更直白的，當第三方的客戶端想着調用咱們這邊的用戶信息，來登錄他們的網站，那麼它得得到這個用戶的認證受權。

大部分的流行API都會實現這一種受權類型。好比說Facebook，當用戶想着登錄咱們的網站，咱們能夠先把用戶重定向到Facebook，讓他先登錄Facebook，而後Facebook會詢問這個用戶，是否贊成咱們的這個網站獲取他在Facebook網站上的用戶信息呢？用戶點了受權之後，就又會被重定向回咱們的網站，同時呢會附上一條認證碼（Authorization Code），而後呢咱們的網站要利用這個認證碼（Authorization Code），再去向Facebook換取准入令牌（access token），有了准入令牌之後，咱們才能夠進一步獲取該用戶的詳細信息。

這整個過程，又一般被叫作「三條腿的Oauth」（3-Legged OAuth），固然了，還有「兩條腿的Oauth」（2-Legged OAuth），也就是接下來的這一種。

2. 模糊受權（Implicit Grant）

Implicit，是模糊、含蓄、不具體指明的意思，這裏呢譯做模糊。模糊受權（Implicit Grant），跟上面的認證碼受權（Authorization Code）相似，不一樣的是，咱們的資源服務器，返回的直接就是准入令牌（access token），而不是認證碼（authorization code）。所以呢，就不是須要三步才能得到token。「三條腿的Oauth」被證實是更好的，可能你會納悶，既然更好，還要這個「兩條腿」的模糊受權（Implicit Grant）幹啥？

認證碼（authorization code）受權，須要的是一個服務器向另外一個服務器（Facebook）發起請求，獲取認證碼，而後交換准入令牌。但若是咱們面前是一個JS的APP，它只是一個瀏覽器端，那麼就很難獲取了認證碼再交換准入token了，這種狀況下，咱們就須要用到這種模糊受權（Implicit Grant）

3. 用戶密碼受權（Resource Owner Password Credentials Grant）

Resource Owner == User

這種類型適合於咱們信任的客戶端，好比咱們本身的手機APP來訪問網站數據，這個時候，客戶端直接使用用戶的登錄密碼信息請求資源服務器，服務器直接返回准入令牌（access token）。

4. 客戶端資質受權（Client Credentials Grant）

這個適合於訪問API的這個客戶端，自己就是相應數據的全部者的時候，這期間不涉及到用戶的互動，說白了就是純粹的機器與機器之間的溝通。好比說一個App想着向用戶顯示一個對話框，或者儲存一些跟這個App相關的數據到咱們的資源服務器上。

5. 令牌刷新受權（Refresh token grant）

當服務器生成一個令牌（token）的時候，同時也會設置一個token的有效期，或者說失效期。令牌刷新受權（Refresh token grant）就是當咱們的token過時了，咱們得須要將其刷新一下，從新生成一個。這種狀況下，驗證服務器會在生成准入token的同時發送一個refresh token（刷新令牌），好後期用來生成一個新的token。須要注意的是，這個流程並不適合於模糊受權（Implicit Grant）。