oauth2.0授權碼

OAuth 2.0提供了許多安全流程（或授權類型），以允許一個應用程序訪問另一個應用程序中的用戶數據。

在此博客中，我們將介紹OAuth 2.0授權：授權代碼授權。

首先，有許多定義：

• 客戶端 ：用戶當前正在與之交互的應用程序。 例如，我們假設一個虛構的時髦博客網站：www.myfunkyblog.com。 客戶端希望與另一個應用程序通信并從那里檢索有關用戶的信息。 例如，他們最喜歡的照片！ 讓我們假設虛擬的megaphotosharing.com作為服務 ? 客戶希望訪問。
• 客戶ID ：這是標識客戶的ID。 可以在Web URL等中公開傳遞
• 客戶機密ID ： 只有客戶知道的機密ID。 這保留在服務器端，將用于請求訪問的應用程序的請求中。 它不能在Web URL中傳遞。
• 資源擁有者 ：這通常是人 ，誰在使用客戶端應用程序。 資源所有者在客戶端（ myfunkyblog.com ）希望訪問的另一個應用程序（例如megaphotosharing.com）中擁有數據。 我們的目標是促進這一共享，而無需資源所有者又名人類有史以來通過他們megaphotosharing.com密碼myfunkyblog.com。 注意：資源所有者不必是人類，但根據OAuth規范 ，有趣的是，資源所有者是人類時，也可以稱為最終用戶。
• 資源服務器 ：托管客戶端感興趣的資源所有者的受保護資源。因此，這是megaphotosharing.com服務器，其中包含myfunkyblog.com感興趣的資源所有者照片。
• 授權服務器 ：誰發出令牌myfunkyblog.com后的資源擁有者成功驗證并允許myfunkyblog.com獲得一些megaphotosharing.com的服務器。 有時，授權服務器和資源服務器實際上是相同的，但不必相同。
• 訪問令牌 ： myfunkyblog.com授權服務器提供的一種特殊類型的令牌，使megaphotosharing.com可以訪問受保護的資源。 它將包含范圍，生存期和其他訪問屬性。

用例

因此，用例是客戶端（ myfunkyblog.com ）希望從另一個應用程序megaphotosharing.com訪問有關資源所有者（人）的信息。

客戶注冊

客戶首先要做的是向服務（ megaphotosharing.com ）注冊，并提供其名稱，網站等。該服務將返回一個秘密的客戶代碼。

客戶將其保密，并負責確保只有其知道。 通常，它將加密并將其持久化在后端的客戶端中。 該服務還將收到一個客戶端ID。 與客戶機密不同，這是公開的，可以在URL等中傳遞。

流

好吧，現在是實際流量。

用戶正在myfunkyblog.com上瀏覽，并訪問myfunkyblog.com想要了解最終用戶最喜歡的照片的網站的一部分。

最終用戶將看到一個彈出屏幕。

該網址：

https://megaphotosharing.com/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL?ope=read

該網址的關鍵部分：

• megaphotosharing.com：這是授權服務器的域
• response_type = code：啟用客戶端所需的參數通知授權服務器所需的授予類型。 一個替代值是“令牌”，用于隱式流。 “代碼”表示客戶端需要授權碼 ，該授權碼將在資源所有者登錄后返回。該授權碼將在客戶端的后續請求中使用。
• client_id：必需參數，用于標識客戶端。 請記住，這是公開的
  可以在Web瀏覽器之間傳遞。
• redirect_uri：這是一個可選參數。 它使客戶端可以動態指定身份驗證服務器應重定向到的URL。 在某些流程中，這是不需要的，因為只有一個重定向URI，并且在客戶端注冊過程中由客戶端使用服務進行了注冊。
• 作用域：這是一個可選參數。 它指定應用程序正在請求的訪問級別。 在這種情況下，這只是讀取。 身份驗證服務器使用它來通知用戶/資源所有者客戶端正在嘗試執行的操作。

然后，用戶登錄megaphotosharing.com，告訴用戶客戶端要做什么。 如果用戶選擇“確定”，則megaphotosharing.com將重定向到傳遞的重定向URI。

https://myfunkyblog.com/callback?code=212132kjhkhj

注意客戶端ID如何通過URL 在Web上傳遞 并將授權代碼通過網絡傳回。

然后，客戶端使用返回的授權碼，客戶端ID，客戶端密碼和授予類型來向服務器發送POST請求，以獲取訪問令牌。 這一切都發生在后端。

https://megaphotosharing.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=?212132kjhkhj&redirect_uri=CALLBACK_URL

筆記：

• 客戶ID和客戶機密標識客戶。 這是一個后端請求，因此可以傳遞client_secret（顯然不會傳遞給瀏覽器或從瀏覽器傳遞）。
• grant_type：必須將其設置為authorisation_code。 因為它表示授權碼授予。 請記住，授予用于指示客戶端正在使用的流（服務器還可以使用哪些類型的可用流）。 如果客戶端正在使用“客戶端證書授予”，則該值為：“ client_credentials”。 如果客戶端使用“資源所有者密碼憑據授予”，則該值為“密碼”。
• 代碼： 212132kjhkhj –實際授權碼，是從授權服務器發出的初始授權請求中返回的內容。 這是必需的。
• redirect_uri：如果redirect_uri包含在授權請求中，則該值必須與該請求中使用的值相同。

客戶端然后接收回訪問令牌。 像這樣：

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":1001013121222}

現在它將使用它來訪問某些資源所有者的資源數據。

那有什么大不了的？

• 對于用戶不必告訴一個網站另一個網站的密碼來說，顯然有很大的優勢。
• 減少用戶需要記住的密碼數量
• 通過允許不同的應用程序相互通信，可以建立更豐富的網站。

人們為什么會感到困惑？

人們發現OAuth 2.0令人困惑的原因有很多。

• 有一些不同的流程或贈款。 授權碼授予只是其中之一。 有時，當您在Google上搜索OAuth 2.0的說明時，會得到針對不同補助金的說明，而沒有弄清楚到底是什么還是沒有解釋。 因此，為什么要在標題中添加授權碼授予。
• 術語。 我只是為自己說話。 但是，如果我快速閱讀，我可能會：
  • 將“客戶”與最終用戶混淆
• 一致。 很多地方都實現了OAuth 2.0或與OAuth非常相似的東西，但是在此過程中它們的引用方式有所不同。 例如，轉到quora.com，然后嘗試登錄google。 您將被帶到： https://accounts.google.com/signin/oauth/oauthchooseaccount?client_id=917071888555.apps.googleusercontent.com&as=rdWeinbqWJbt6ChoW2f3Fg&destination=https%3A%2F%2Fwww.quora.com≈proval_state=!ChRyQlhnbEYzai1xQTliNlNmTEVmNRIfZ3doM2hlRVIycGdiMEVBN1JaNXdOM085MERXLVVCWQ%E2%88%99ANKMe1QAAAAAW2i2to0SOyO2_w3k3O4gjwUKQLGNmZ2h&oauthgdpr=1&xsrfsig=AHgIfE8EzSxvWfzyxou0dwLDxv4GhD6e5g&flowName=GeneralOAuthFlow

  該URL中沒有response_type。

• OAuth是一種授權規范。 它通常與身份驗證規范一起使用，例如Open Connect，但這實際上是一個單獨的規范。

翻譯自: https://www.javacodegeeks.com/2018/08/oauth-authorisation-code-grant.html

oauth2.0授權碼

總結

以上是生活随笔為你收集整理的oauth2.0授权码_OAUTH 2.0授权码授予的全部內容，希望文章能夠幫你解決所遇到的問題。

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