當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

oauth2.0授权码_OAUTH 2.0授权码授予

發布時間：2023/12/3 编程问答 41 豆豆

生活随笔收集整理的這篇文章主要介紹了 oauth2.0授权码_OAUTH 2.0授权码授予小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

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授權碼