本文概述了OAuth 2.0協(xié)議。它討論了OAuth 2.0實現(xiàn)過程中涉及的不同參與者和步驟。

介紹：

OAuth代表開放授權(quán)。它是一個免費開放的協(xié)議，建立在IETF標準和Open Web Foundation的許可之上。它允許用戶與第三方共享其私有資源，同時保密自己的憑據(jù)。這些資源可以是照片，視頻，聯(lián)系人列表，位置和計費功能等，并且通常與其他服務提供商一起存儲。OAuth通過在用戶批準訪問權(quán)限時向請求（客戶端）應用程序授予令牌來執(zhí)行此操作。每個令牌在特定時間段內(nèi)授予對特定資源的有限訪問權(quán)限。

1. Oauth2是一個授權(quán)協(xié)議：

OAuth2支持“委派身份驗證”，即授予對其他人或應用程序的訪問權(quán)限以代表您執(zhí)行操作。考慮一下這種情況：你開車去一家優(yōu)雅的酒店，他們可能會提供代客泊車服務。然后，您授權(quán)代客服務員通過將鑰匙交給他來開車，以便讓他代表您執(zhí)行操作。

OAuth2的工作方式類似 - 用戶授予對應用程序的訪問權(quán)限，以代表用戶執(zhí)行有限的操作，并在訪問可疑時撤消訪問權(quán)限。

2.參與OAuth2的參與者：

i）資源服務器：托管受OAuth2保護的用戶擁有資源的服務器。資源服務器驗證訪問令牌并提供受保護資源。

ii）資源所有者：通常，應用程序的用戶是資源所有者。資源所有者能夠授予或拒絕訪問資源服務器上托管的自己的數(shù)據(jù)。

iii）授權(quán)服務器：授權(quán)服務器獲得資源所有者的同意，并向客戶端發(fā)出訪問令牌以訪問資源服務器托管的受保護資源。

iv）客戶端：應用程序使API請求代表資源所有者對受保護資源執(zhí)行操作。在它可以這樣做之前，它必須由資源所有者授權(quán)，并且授權(quán)必須由資源服務器/授權(quán)服務器驗證。OAuth2根據(jù)其與授權(quán)服務器安全身份驗證的能力（即，維護其客戶端憑據(jù)機密性的能力）定義了兩種客戶端類型：

a）機密：客戶能夠保持其憑證的機密性。機密客戶端在安全服務器上實現(xiàn)，具有對客戶端憑證的受限訪問（例如，在Web服務器上運行的Web應用程序）。

b）公共：客戶端無法維護其憑據(jù)的機密性（例如，已安裝的本機應用程序或基于Web瀏覽器的應用程序），并且無法通過任何其他方式進行安全的客戶端身份驗證。

3.您是應用程序開發(fā)人員，這是一個用例：

考慮一個場景。您正在開發(fā)一個有趣的Facebook應用程序，并將其稱為“FunApp”。FunApp需要訪問用戶的公開個人資料，照片，帖子，朋友等。現(xiàn)在問題是，FunApp如何獲得用戶從Facebook訪問他/她的數(shù)據(jù)的權(quán)限，同時告知Facebook用戶已授予此權(quán)限FunApp使Facebook能夠與這個應用程序共享用戶的數(shù)據(jù)？

舊方式：用戶與FunApp共享他/她的Facebook憑據(jù)（用戶名，密碼）。這種方法存在一些挑戰(zhàn)：信任，不受限制的訪問，用戶對Facebook密碼的更改等。

OAuth2方式：如果應用需要訪問其用戶數(shù)據(jù)，Funapp會將用戶重定向到Facebook上的授權(quán)頁面。用戶將登錄其帳戶并授予訪問權(quán)限，然后FunApp將從Facebook獲取訪問令牌以訪問用戶的數(shù)據(jù)。雖然Oauth2已經(jīng)解決了這些挑戰(zhàn)，但它也為開發(fā)人員創(chuàng)造了成本。

讓我們從開發(fā)人員的角度看這個場景，并找出這里涉及的演員：

• 由于Facebook擁有所有資源（用戶的公開個人資料，照片，帖子，朋友等），因此它成為資源服務器。
• 用戶是資源所有者。
• 當FunApp請求用戶的受保護資源時，它將成為客戶端。
• 當Facebook獲得用戶同意并向FunApp發(fā)出訪問令牌時，它將成為授權(quán)服務器。

4.注冊客戶端（FunApp）和獲取客戶端憑據(jù)：

OAuth要求客戶端向授權(quán)服務器注冊。授權(quán)服務器請求有關(guān)客戶端的一些基本信息，例如name，redirect_uri（授權(quán)服務器在資源所有者授予權(quán)限時將重定向到的URL）并將客戶端憑據(jù)（client-id，client-secret）返回給客戶端。在執(zhí)行諸如交換訪問令牌的授權(quán)碼和刷新訪問令牌等操作時，這些憑證對于保護請求的真實性至關(guān)重要。

例如，Facebook要求您在Facebook Developers門戶網(wǎng)站上注冊您的客戶端。轉(zhuǎn)到Facebook開發(fā)人員門戶網(wǎng)站并注冊FunApp并獲取客戶端憑據(jù)。

5.逐步獲取訪問令牌：

FunApp需要從Facebook獲取訪問令牌才能訪問用戶的數(shù)據(jù)。為了獲得訪問令牌，FunApp將用戶重定向到Facebook的登錄頁面。成功登錄后，Facebook會重定向到redirect_uri（在步驟4中注冊）以及短期授權(quán)代碼。FunApp交換授權(quán)代碼以獲取長期訪問令牌。訪問令牌用于訪問用戶的數(shù)據(jù)。這是OAuth2中最受歡迎的流程，稱為授權(quán)代碼授權(quán)。以下是在授權(quán)代碼授權(quán)中獲取訪問令牌的序列圖：

6. 了解授權(quán)授權(quán)類型：

要獲取訪問令牌，客戶端將從資源所有者獲取授權(quán)。授權(quán)以授權(quán)授權(quán)的形式表示，客戶端使用該授權(quán)授權(quán)來請求訪問令牌。OAuth2定義了四種標準授權(quán)類型：授權(quán)代碼，隱式，資源所有者密碼憑據(jù)和客戶端憑據(jù)。它還提供了一種用于定義其他授權(quán)類型的擴展機制。

i）授權(quán)代碼授權(quán)：此授權(quán)類型針對機密客戶端（Web應用程序服務器）進行了優(yōu)化。授權(quán)代碼流不會將訪問令牌公開給資源所有者的瀏覽器。相反，使用通過瀏覽器傳遞的中間“授權(quán)代碼”來完成授權(quán)。在對受保護的API進行調(diào)用之前，必須將此代碼交換為訪問令牌。

ii）隱性撥款：此撥款類型適用于公共客戶。隱式授權(quán)流程不適用刷新令牌。如果授權(quán)服務器定期過期訪問令牌，則只要需要訪問權(quán)限，您的應用程序就需要運行授權(quán)流程。在此流程中，在用戶授予所請求的授權(quán)后，會立即將訪問令牌返回給客戶端。不需要中間授權(quán)代碼，因為它在授權(quán)代碼授權(quán)中。

iii）資源所有者密碼憑證：資源所有者密碼憑證授權(quán)類型適用于資源所有者與客戶端具有信任關(guān)系并且資源所有者同意與客戶端共享他/她的憑證（用戶名，密碼）的情況。然后，客戶端可以使用所有者憑據(jù)中的資源從授權(quán)服務器獲取訪問令牌。

iv）客戶端憑據(jù)：當客戶端本身擁有數(shù)據(jù)且不需要資源所有者的委派訪問權(quán)限，或者已經(jīng)在典型OAuth流程之外授予應用程序委派訪問權(quán)限時，此授權(quán)類型是合適的。在此流程中，不涉及用戶同意。客戶端交換其客戶端憑據(jù)以獲取訪問令牌。

7.令牌已過期，獲取新的訪問令牌：

如果訪問令牌由于令牌已過期或已被撤銷而不再有效，則使用OAuth 2.0訪問令牌進行API調(diào)用可能會遇到錯誤。在這種情況下，資源服務器將返回4xx錯誤代碼。客戶端可以使用刷新令牌（在授權(quán)代碼交換訪問令牌時獲得）獲取新的訪問令牌。

8.結(jié)論：

這是嘗試提供OAuth 2.0過程的概述，并提供獲取訪問令牌的方法。我希望它有所幫助。

享受整合應用的樂趣！

英文原文：dzone.com/articles/oa…

查看更多文章

公眾號:銀河系1號

聯(lián)系郵箱：public@space-explore.com

轉(zhuǎn)載于:https://juejin.im/post/5cc29c726fb9a031ec6d2cac

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的OAuth 2.0初学者指南的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。