本文來自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）。