在本文中，我們學習如何使用Spring boot輕松配置和部署微服務，然后使用OAuth和OpenID保護它們。

在微服務體系架構中，其中較大的應用程序由多個較小的服務組成，每個服務都有自己的目標，它們通過網絡進行協作和通信，以實現特定的目標。在微服務體系結構中，每個服務都在自己的進程中運行，并使用輕量級機制(如HTTP/REST和JSON)與其他進程通信。

微服務，它為項目工程、可擴展性和性能提供了好處。將單個應用程序劃分為不同的組件意味著可以同時開發和部署每個組件，但又可以分別進行。

當我們將微服務體系結構與單片應用程序設計進行比較時，它就更有意義了。在單片體系結構設計中，我們創建了一個大的、笨重的應用程序，所有模塊都緊密耦合在一個可執行文件中，這個可執行文件通常部署在Web或應用服務器上。

典型的單片架構應用程序如下所示：

微服務示例：

微服務設計的關鍵指南

• 松耦合、獨立和高性能

• 獨立的擴展、部署、監視和管理，不影響任何其他應用程序或服務

• 單一責任原則

• 更快的開發和發布周期

Spring Boot概述

首先，Spring Boot不是一個框架，它是一種輕松創建具有最小配置或零配置的獨立應用程序的方法。 這是一種開發基于敏捷開發的應用程序的方法，配置非常少。 它提供了代碼和注釋配置的默認值，可以在短時間內快速啟動新的Spring項目。

為什么選擇Spring Boot？

• 使用Java開發基于Spring的應用程序非常容易。

• 它減少了大量的開發時間并提高了生產率。

• 它避免編寫大量的樣板代碼，注釋和XML配置。

• 將Spring Boot應用程序與Spring生態系統集成在一起非常容易，如Spring JDBC，Spring ORM，Spring Data，Spring Security等。

• 它提供了嵌入式HTTP服務器，如Tomcat和Jetty，可以非常輕松地開發和測試Web應用程序。

為什么Spring Boot用于微服務？

第一個好處是Spring Boot通過將Spring應用程序中的Convention over Configuration(CoC)提升到一個全新的水平，大大簡化了應用程序配置。Spring Boot有一個稱為自動配置的功能，可以智能地提供一組由類路徑上的jar驅動的默認行為。因此，在保留定制應用程序的能力的同時，很容易在很少或沒有配置的情況下啟動和運行新的微服務。

Spring boot的第二個好處是，它允許您將應用程序打包為包含預配置的嵌入式Web容器(Tomcat或Jetty)的可執行JAR，從而簡化了部署。這樣就無需在服務器上安裝和配置Tomcat或Jetty。相反，要運行微服務，只需安裝Java即可。此外，可執行JAR格式提供了一種統一的、自包含的方式來打包和運行JVM應用程序，而不管其類型如何，這簡化了操作。

為什么要考慮微服務安全？

當您的項目從一個整體架構轉移到微服務架構時，安全性可能是一個重要方面。微服務體系結構本質上是高度分布的，其特點是網絡流量增加。通常，業務數據可以通過RESTAPI訪問，如果不正確地保護它們，則很容易被盜。這些調用應該通過使用HTTPS協議來防止中間節點攻擊，但是API端點也必須是安全的。安全檢查的工作應該與調用微服務API的工作很好地平衡，否則您的體系結構將永遠無法很好地執行。為了保護每個服務節點，每個微服務都應該獲得一個標識和一組權限，以便API端點安全組件能夠驗證這兩者。

使用OAuth 2.0的Spring安全性

關于OAuth到底是什么有很多困惑。

有些人認為OAuth是一個登錄流(比如，當你使用微信登錄登錄到一個應用程序時)，有些人認為OAuth是一個“安全的東西”，實際上并不了解更多。

我將引導您了解OAuth是什么，解釋OAuth是如何工作的，并希望讓您了解OAuth如何以及在何處對您的應用程序有利。

什么是OAuth 2.0？

首先，OAuth不是API或服務：它是一個開放的授權標準，任何開發人員都可以實現它。

OAuth是應用程序可以用來向客戶端應用程序提供“安全授權訪問”的標準。OAuth通過HTTP工作，并使用訪問令牌而不是憑據來授權設備、API、服務器和應用程序。

OAuth有兩個版本：OAuth 1.0和OAuth 2.0。 這些規范彼此完全不同，不能一起使用：它們之間沒有向后兼容性。

OAuth 2.0的作用是什么？

OAuth基本上是一個支持授權工作流的協議。這意味著它為您提供了一種確保特定用戶具有執行某項操作的權限的方法。

OAuth并不是要做像驗證用戶身份這樣的事情——這是由身份驗證服務負責的。身份驗證是指驗證用戶的身份(如要求用戶名/密碼登錄)，而授權是指檢查現有用戶已經擁有的權限。

為什么選擇OAuth 2.0？

輕松：朋友會向您發送有趣圖片或視頻的鏈接，您想發表評論。唯一的問題是，你以前從未去過這個網站，也沒有帳戶。當你花幾秒鐘考慮是否值得注冊時，你會看到一個“用你的微信帳戶登錄”按鈕。成功！你是數億微信用戶中的一員，所以這是一個非常簡單的OAuth替代方案。

安全性：自從OAuth 2.0(現在是標準模型)問世以來，所有OAuth數據傳輸都必須在SSL(安全套接字層)上進行，以確保使用最可信的加密行業協議盡可能地保證數據的安全。

受歡迎程度：。OAuth已經被騰訊，阿里，百度，谷歌、Facebook、Twitter等公司所采用。

時間：不僅很容易，而且從長遠，這是非常節省時間的。無論是在網上找到一個新的網站還是返回到最喜歡的網站，如果你經常訪問支持OAuth的網站，那么你只需要為你訪問的網站授權創建一個帳戶即可。這就相當于晚上去一個新的俱樂部，讓一個非常酷的朋友帶你走到隊伍的最前面，讓保鏢舉起繩子讓你繞開漫長的等待。

OAuth 2.0示例?

一位外賓A對接待處說，他想與員工B見面，以方便商務活動。

接待處通知員工B，客人A來拜訪他。

員工B來到接待處，確認客人A的身份。

員工B在前臺記錄客人A的業務目的和身份。

接待處向A客人發放訪客卡。

員工B和客人A去指定的房間討論他們的業務。

我給出這個示例是為了幫助您理解簽發OAuth和授權的過程。訪客卡只允許訪客進入預先確定的地方，這意味著持有“訪客卡”的人不能進入持有“員工ID卡”的人可以進入的所有地方。這樣，直接登錄服務的用戶可以做的比OAuth授權的用戶多。

在OAuth中，“auth”是指“授權”和“身份驗證”，因此，在執行OAuth的身份驗證時，服務提供商(接待臺)會詢問用戶(員工)是否希望授權第三方應用程序(來賓)的請求。下圖顯示了Facebook如何詢問您是否要授予對第三方應用程序的訪問權限。

OAuth 2.0-關鍵概念

至少，您應該了解OAuth2中的四個關鍵概念：

• OAuth2角色

• OAuth2授權授予類型

• OAuth2令牌

• OAuth2令牌訪問范圍

• 讓我們一個接一個地討論關鍵概念。

OAuth 2.0角色

OAuth 2.0定義了四個角色：

資源所有者：一般是你自己。能夠授予受保護資源訪問權的實體。當資源所有者是一個人時，它被稱為最終用戶。

資源服務器：托管受保護數據的服務器

客戶端應用程序：請求訪問資源服務器的應用程序授權服務器：服務器向客戶端發出訪問令牌。 此令牌將用于客戶端請求資源服務器。

OAuth 2.0授權：

授權是表示客戶端用于獲取訪問令牌的資源所有者授權(訪問其受保護資源)的憑證。規范定義了四種授權類型：

授權代碼：一旦客戶端是Web服務器，就應該使用它。 它允許您獲取長期訪問令牌，因為它可以使用刷新令牌續訂(如果授權服務器啟用它)。

隱式：通常在客戶端使用腳本語言(如Javascript)在瀏覽器中運行時使用。 此授權類型不允許發布刷新令牌。

資源所有者密碼憑據：當客戶端和服務器都來自信任所在的同一公司時，最適合授予“密碼憑據”，您不想向第三方提供憑據。

客戶端憑據：當客戶端本身是資源所有者時，使用這種類型的授權。沒有從最終用戶獲得授權。

OAuth 2.0令牌

令牌是由授權服務器生成的隨機字符串，在客戶機請求時發出。

令牌有兩種類型：

訪問令牌：此令牌由客戶機作為參數或作為請求中的頭發送到資源服務器。它的生存期有限，由授權服務器定義。它必須盡快保密，但我們會發現這并不總是可能的，特別是當客戶機是通過javascript向資源服務器發送請求的Web瀏覽器時。

刷新令牌：它只在訪問令牌過期時發送到授權服務器以更新訪問令牌。出于安全原因，不可能總是獲得此令牌。

OAuth 2.0令牌范圍

客戶端可以使用作用域[要訪問此用戶帳戶的源和照片]和授權服務器請求具有特定訪問權限的資源，然后返回顯示實際授予客戶端哪些訪問權限的作用域[例如，資源所有者僅允許源訪問，沒有照片]。

訪問令牌可以通過多種方式發送到資源服務器。

請求參數(GET或POST)：使用GET的示例：https://api.example.com/profile?access_token=MzJmNDc3M2VjMmQzN授權標題：GET / profile HTTP / 1.1主持人：api.example.com授權：Bearer MzJmNDc3M2VjMmQzN

OAuth 2.0流程

這里我們有兩個端點：授權端點令牌端點還有資源所有者Joe。因此，必須有兩件事來實現這個OAuth：

Joe應該擁有Gmail帳戶。我的應用程序應該在Google注冊。

因此，我的應用程序向Authorization Endpoint發送請求，在此請求中，它只是說這是我的客戶端ID。在這里，它沒有發送密鑰。我想訪問這些電子郵件。它沒有具體說明哪個電子郵件。它只是說資源的類型。因此，OAuth驗證了這一點，當事情正常時，它會將請求轉發給資源所有者并說：“嘿資源所有者，首先我希望您進行身份驗證。” 這通過將登錄頁面發送給資源所有者來實現。資源所有者通過將他的用戶ID和密碼發送到auth服務器來驗證自己，并且在驗證之后，另一個網頁生成并告訴資源所有者，名為My App的應用程序想要訪問您的電子郵件。它詢問您是否要允許訪問電子郵件。通常，用戶可以選擇在屏幕上單擊“是”或“否”。大多數情況下，用戶說是，然后請求返回到Auth服務器。

此后，auth服務器生成auth代碼，然后返回到應用程序my app。現在，是時候驗證我的應用了。這意味著現在我們要驗證應用程序的身份。我們怎么做？我們用紅色鑰匙來做。紅鍵是客戶機ID，尤其是客戶機機密，它只為應用程序和OAuth服務器所知。為了進行驗證，如果客戶機ID和客戶機機密相同(如果您的重定向URI匹配)，它會將身份驗證代碼、客戶機ID和客戶機機密發送到令牌端點。所有這些檢查都在令牌端點完成。

如果一切正常，則生成訪問令牌并將其發送回應用程序，即“我的應用程序”。現在，訪問令牌需要安全地存儲它。通常，令牌有效。現在，應用程序將訪問令牌發送到資源服務器并說“這是訪問令牌。我想訪問電子郵件。” 現在，資源服務器必須驗證令牌是否有效。在這種情況下，資源服務器將令牌發送到OAuth服務器令牌端點，并且服務器在數據庫中檢查令牌是否有效，是否已過期，以及它是否包含正確的范圍。

在所有這些檢查之后，結果將作為有效或無效的結果返回到資源服務器。如果一切都有效，資源服務器將向資源發送請求，并獲取數據并將其發送到應用程序“我的應用程序”。

OpenID連接

OpenID Connect是OAuth 2.0協議之上的一個簡單標識層，它允許計算客戶端根據授權服務器執行的身份驗證來驗證最終用戶的身份，并獲取有關最終用戶的基本配置文件信息。

OpenID與OAuth 2.0OpenID是一種標準的身份驗證協議，它也使用HTTP，就像OAuth一樣。 但是，OpenID的目的與OAuth的目的不同。

OpenID的主要目的是身份驗證，而OAuth則是授權。 因此，使用OpenID基本上與登錄相同。 對于OpenID，OpenID Provider處理用戶身份驗證過程。 許多依賴Open ID的參與者將身份驗證委托給OpenID提供商。

除了授權之外，OAuth還具有其身份驗證過程。例如，當使用Facebook OAuth時，Facebook服務提供商會對Facebook用戶進行身份驗證。但是，OAuth的基本目的是確定用戶是否有權調用API在用戶網頁上書寫，或者API獲取好友列表。

您可以使用OAuth進行用戶身份驗證；但是，請注意，它的基本目的是授權用戶。這與OpenID的目標不同。

為何選擇OpenID？注冊更快更容易
登錄更快捷，更輕松
更接近統一的“網絡身份”

關于OpenID的更多信息

長按訂閱更多精彩▼

總結

以上是生活随笔為你收集整理的springboot jar服务器运行后无法请求_Spring boot、微服务、OAuth、OpenID的爱恨情仇！...的全部內容，希望文章能夠幫你解決所遇到的問題。

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