OAuth協議簡介

1、oauth協議是什麼

關於oauth，不在長篇大論的講了，以乙個例子說明。

如何得到使用者的授權呢？傳統思想是跟使用者要賬號、密碼。這就存在問題了，首先使用者不願意給，再者即使給了也存在很多問題：

2）使用者只有修改密碼，才能收回授權。

3）密碼洩露的可能性大大提高。

這個場景可以使用oauth來實現，使用oauth不需要使用者告訴第三方應用使用者名稱、密碼，而是交給第三方應用乙個令牌（token），當第三方應用訪問使用者資料的時候帶著令牌。令牌可以指定只能訪問哪些資料，也可以指定有效期。

2、oauth協議中的角色

oauth協議中總的來說涉及到3個角色：服務提供商、資源所有者、第三方應用。

服務提供商（provider）：邏輯上分為認證伺服器和資源伺服器，其實可以寫在乙個應用上。

認證伺服器（authorization server）：認證使用者的身份、產生令牌。

資源伺服器（resource server）：儲存使用者的資源、驗證令牌。

3、oauth協議的流程

1）使用者訪問第三方應用，第三方應用請求資源所有者授權（使用者就是資源所有者）。

2）資源所有者同意授權。

3）第三方應用訪問認證伺服器申請令牌。

4）認證伺服器驗證使用者確實授權了，就發放令牌給第三方應用。

5）第三方應用拿到了令牌，帶著令牌訪問資源伺服器申請獲取資源。

6）資源伺服器驗證令牌無誤後，把資源開放給第三方應用。

4、oauth協議中4種授權模式

從上面流程的第二步可以看到，第三方應用需要資源所有者授權。oauth協議中4種授權模式：

1）授權碼模式（authorization code）

2）簡化模式（implicit）使用少

3）密碼模式（resource owner password credentials）

4）客戶端模式（client credentials）使用少

這4種模式中簡化模式和客戶端模式使用很少。授權碼模式功能最完整，邏輯最嚴密，絕大多數服務提供商是採用該模式。

5、授權碼模式流程

過程：使用者訪問第三方應用，第三方應用將使用者導向認證伺服器授權，授權後，認證伺服器返回授權碼，第三方應用攜帶授權碼去申請令牌。

1）第三方應用需要使用者授權，會將使用者導向認證伺服器。

2）使用者同意授權（使用者授權的動作在認證伺服器上完成）。

3）認證伺服器會將使用者重新導回到第三方應用上去，同時返回乙個授權碼，導到哪個位址上是第三方應用和認證伺服器提前商量好的。

4）第三方應用在收到授權碼以後攜帶授權碼去認證伺服器申請令牌（發出申請動作在第三方應用上完成的，使用者不可見）。

5）認證伺服器核對第三方應用攜帶的授權碼是不是第三步發的，如果是則向第三方應用發放令牌。

授權碼模式的特點：

1）使用者同意的動作是在認證伺服器上完成的，其他3種模式是在第三方應用上完成的。

2）使用者同意授權，返回第三方時攜帶的不是令牌，而是授權碼，第三方拿著授權碼再去換取令牌。

授權碼模式的好處：

使用者授權時在認證伺服器儲存授權碼，第三方應用請求令牌時攜帶該授權碼進行對比，更加安全。如果使用者同意的動作在第三方應用上完成，然後第三方應用拿著使用者同意的憑證資訊去認證伺服器申請令牌的話，不夠安全，因為第三方應用可以偽造憑證資訊。認證伺服器無法確定使用者是否真正的授權了。