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

介紹：

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

1. Oauth2是一個授權協議：

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

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

2.參與OAuth2的參與者：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例如，Facebook要求您在Facebook Developers門戶網站上注冊您的客戶端。轉到Facebook開發人員門戶網站并注冊FunApp并獲取客戶端憑據。

5.逐步獲取訪問令牌：

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

6. 了解授權授權類型：

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

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

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

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

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

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

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

8.結論：

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

享受整合應用的樂趣！

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

查看更多文章

公眾號:銀河系1號

聯系郵箱：public@space-explore.com

轉載于:https://juejin.im/post/5cc29c726fb9a031ec6d2cac

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。