Laravel Passport里的授權(quán)類型介紹

RobinTang 發(fā)布于2019-06-28 18:36 / 418人閱讀

摘要：模糊授權(quán)，跟上面的認證碼授權(quán)類似，不同的是，我們的資源服務(wù)器，返回的直接就是準入令牌，而不是認證碼。

本文來自pilishen.com----原文鏈接; 歡迎來和pilishen一起學習php&Laravel；學習群：109256050

OAuth2是一個安全框架，控制著程序受保護部分的準入，主要是控制不同的客戶端如何來調(diào)取API，保證它們在請求相應(yīng)資源的時候有相應(yīng)的權(quán)限。

Laravel Passport是一個強大的Oauth2服務(wù)實現(xiàn)，使用Passport往往已經(jīng)足以應(yīng)對我們?nèi)粘PI開發(fā)中的各種需求，甚至說，大部分時候，我們只是用到了Passport的部分功能而已。也正因為其強大，所以理解和使用起來也有一定難度，而這其中，理解和熟悉oauth2相關(guān)的各種授權(quán)類型是關(guān)鍵，授權(quán)類型理解了，Passport也就沒什么難的了。話不多說，一起來看看不同的授權(quán)類型都是怎么回事吧。

概念理解： 1. 客戶端（Client）

指的是調(diào)取你程序API的那個應(yīng)用，或者說終端，在Passport里創(chuàng)建客戶端可以通過artisan命令來進行

php artisan passport:client

每一個客戶端（client）都要有一個key, name, secret, redirect URI, user（程序創(chuàng)建者/所有者）

2. 資源擁有者（Resource Owner）

這個指的是客戶端請求的那個API，其背后所對應(yīng)資源（或者說數(shù)據(jù)）的所有者（user）

3. 資源服務(wù)器（Resource Server）

這個也就是我們的API，可以是不需要讀取權(quán)限的公共數(shù)據(jù)，也可以是需要驗證權(quán)限的私有數(shù)據(jù)。公共數(shù)據(jù)，或者說公開節(jié)點（endpoints），舉個例子就是比如說搜索所有的tweets消息，或者說搜索微信文章，這不需要特別的權(quán)限，誰都可以搜。另一方面，假設(shè)說以某個用戶的名義去發(fā)布（post）一個推特消息，發(fā)一個朋友圈，就需要來自這個用戶的權(quán)限認證了。

4. 權(quán)限范圍（Scope）

指的是獲取特定數(shù)據(jù)，或者進行特定操作的權(quán)限（permission），可以在AuthServiceProvider使用Passport::tokensCan()方法來具體定義權(quán)限（scope）

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

5. 準入令牌（Access token）

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

授權(quán)類型（Grant Type）

授權(quán)（Grant），說白了就是從資源服務(wù)器獲取準入令牌（Access token）的方式，也可以更通俗地說成頒發(fā)令牌（token）的方式。一共有五種授權(quán)方式，其中四種是用來獲取令牌（Access token）的，另一個是用來刷新、或者說重新創(chuàng)建一個已有令牌（token）的。

1. 認證碼授權(quán)（Authorization Code grant）

這是最常見的一種類型，說白了就是第三方登陸，也即當?shù)谌降某绦蛳胫@取我們這邊的受保護信息，這個第三方程序必須得獲得我們這邊用戶的認證授權(quán)。更直白的，當?shù)谌降目蛻舳讼胫{(diào)用我們這邊的用戶信息，來登陸他們的網(wǎng)站，那么它得獲得這個用戶的認證授權(quán)。

大部分的流行API都會實現(xiàn)這一種授權(quán)類型。比如說Facebook，當用戶想著登陸我們的網(wǎng)站，我們可以先把用戶重定向到Facebook，讓他先登陸Facebook，然后Facebook會詢問這個用戶，是否同意我們的這個網(wǎng)站獲取他在Facebook網(wǎng)站上的用戶信息呢？用戶點了授權(quán)以后，就又會被重定向回我們的網(wǎng)站，同時呢會附上一條認證碼（Authorization Code），然后呢我們的網(wǎng)站要利用這個認證碼（Authorization Code），再去向Facebook換取準入令牌（access token），有了準入令牌以后，我們才可以進一步獲取該用戶的詳細信息。

這整個過程，又通常被叫做“三條腿的Oauth”（3-Legged OAuth），當然了，還有“兩條腿的Oauth”（2-Legged OAuth），也就是接下來的這一種。

2. 模糊授權(quán)（Implicit Grant）

Implicit，是模糊、含蓄、不具體指明的意思，這里呢譯作模糊。模糊授權(quán)（Implicit Grant），跟上面的認證碼授權(quán)（Authorization Code）類似，不同的是，我們的資源服務(wù)器，返回的直接就是準入令牌（access token），而不是認證碼（authorization code）。因此呢，就不是需要三步才能獲得token。“三條腿的Oauth”被證明是更好的，可能你會納悶，既然更好，還要這個“兩條腿”的模糊授權(quán)（Implicit Grant）干啥？

認證碼（authorization code）授權(quán)，需要的是一個服務(wù)器向另一個服務(wù)器（Facebook）發(fā)起請求，獲取認證碼，然后交換準入令牌。但如果我們面前是一個JS的APP，它只是一個瀏覽器端，那么就很難獲取了認證碼再交換準入token了，這種情況下，我們就需要用到這種模糊授權(quán)（Implicit Grant）

3. 用戶密碼授權(quán)（Resource Owner Password Credentials Grant）

Resource Owner == User

這種類型適合于我們信任的客戶端，比如我們自己的手機APP來訪問網(wǎng)站數(shù)據(jù)，這個時候，客戶端直接使用用戶的登陸密碼信息請求資源服務(wù)器，服務(wù)器直接返回準入令牌（access token）。

4. 客戶端資質(zhì)授權(quán)（Client Credentials Grant）

這個適合于訪問API的這個客戶端，本身就是相應(yīng)數(shù)據(jù)的所有者的時候，這期間不涉及到用戶的互動，說白了就是純粹的機器與機器之間的溝通。比如說一個App想著向用戶顯示一個對話框，或者儲存一些跟這個App相關(guān)的數(shù)據(jù)到我們的資源服務(wù)器上。

5. 令牌刷新授權(quán)（Refresh token grant）

當服務(wù)器生成一個令牌（token）的時候，同時也會設(shè)置一個token的有效期，或者說失效期。令牌刷新授權(quán)（Refresh token grant）就是當我們的token過期了，我們得需要將其刷新一下，重新生成一個。這種情況下，驗證服務(wù)器會在生成準入token的同時發(fā)送一個refresh token（刷新令牌），好后期用來生成一個新的token。需要注意的是，這個流程并不適合于模糊授權(quán)（Implicit Grant）。