沒有強不強一說，他們都是實現系統角色許可權認證的框架，多數情況下並不是拿來即用，而是需要針對不同的專案進行擴充套件開發，二次開發。如果你對他們瞭解的深，很清楚的明白過濾器鏈等底層實現原理，那就可以讓他們變得更強。開發者強，框架就強。框架只是給你一個通用的解決方案，強不強的還是在開發者怎麼樣去改造使用它。

另外，即使是在微服務時代，shiro也很好用，可以改造stateless模式就可以達到和spring security一樣的效果了，重點是輕量級！上手快！

我是不推薦用shiro了，Spring cloud Gateway裡面你是無法整合shiro的，一個是webflux，一個是servlet。當然你可以獨立成服務。shiro原始碼感覺沒有Spring security寫得好，如果屬性比較多，屬性變化比較多，感覺效能沒有Spring security好。

相對於Apache Shiro，Spring Security提供了更多的諸如LDAP、OAuth2.0、ACL、Kerberos、SAML、SSO、OpenID等諸多的安全認證、鑑權協議，可以按需引用。對認證/鑑權更加靈活，粒度更細。可以結合你自己的業務場景進行更加合理的定製化開發。在最新的Spring Security 5.x中更是提供了響應式應用（reactive application）提供了安全控制支援。從語言上來講，支援使用kotlin、groovy進行開發。Spring Security因為是利用了Spring IOC 和AOP的特性而無法脫離Spring獨立存在。

而Apache Shiro可以獨立存在。但是Java Web領域Spring可以說是事實上的J2EE規範。使用Java技術棧很少能脫離Spring。也因為功能強大Spring Security被認為非常重，這是不對的。認真學習之後會發現其實也就是那麼回事。兩種框架都是非常優秀的安全框架，根據實際需要做技術選型。

如果你使用微服務建議使用 Spring Seucurity ,比較簡單的應用可以使用Shiro。Spring Seucurity 學習起來也不難，我出了一個從零開始的Spring Security教程，目前廣受好評，你可以到我個人部落格felord.cn去免費獲取。

比較：Java EE安全性，Apache Shiro與Spring安全性

抽象

本文根據自定義類別將Java EE Security與Apache Shiro和Spring Security進行了比較。它針對希望獲得一個大致概念的讀者，該選擇哪種框架來保護其應用程式。因此，本篇文章將不深入。為了提供一些上下文，我們將簡要介紹測試環境。然後進行實際比較。自定義類別為文件，易用性，社群支援和差異化功能。結論中總結了我們的發現。

簡要概述

Java EE安全性API

Java EE應用程式通常包含多個元件。甲容器保持這些部件。Java EE的安全性模型指定容器必須提供或支援某些安全性功能。您可以透過兩種方式實現這些功能：宣告式和程式設計式。

宣告性的：開發人員在部署描述符和/或程式碼中使用註釋指定安全要求。關於註釋的最酷的事情是，您可以將它們放在類和/或方法上，而不用編寫冗長的XML程式碼。

程式化的：提供基於安全上下文做出與安全相關的決策的能力。如果註釋和部署描述符的表達能力不夠，“ Java EE教程，第7版”文件建議使用此方法。一個示例是使資源僅在一天的特定時間訪問。

兩種方法都基於Java身份驗證和授權服務（JAAS） API。

Apache ShiroApache Shiro

的兩個主要特徵（“ shiro” = jap。“ castle”）是簡單性和容器獨立性。它的核心功能是身份驗證，授權，加密和會話管理。

身份驗證設計簡單而直觀。該過程是基於主題的，由開發人員僅使用幾個方法呼叫來執行。豐富的異常層次結構有助於錯誤診斷。記住，我本身就包含功能。可插拔DAO可以用於實現領域，並且可以將一個主題登入到多個領域，同時保持其統一檢視。

授權也是基於主題的。訪問許可權由主題角色和許可權確定。要立即開始實施許可權，可以使用Shiro的自制萬用字元許可權語法。為了改善使用者體驗和效能，支援不同的快取解決方案。

密碼學功能以簡單性為中心。Shiro的主要目標是使Java密碼學擴充套件易於使用。由於Shiro的API是介面驅動和基於POJO的，因此可以使用任何JavaBeans相容格式輕鬆配置加密元件。

即使對於非基於Web的應用程式，也可以使用Shiro進行會話管理。由於會話物件也是POJO的物件，因此可以將它們持久儲存在任何型別的儲存中。一些更流行的快取解決方案也可以在這裡使用。

此外，Shiro還提供特定於Web的功能。透過透過web.xml為您的應用程式啟用Shiro，您可以保護任何URL，還可以為每個URL指定過濾器鏈。

Spring Security

與前兩個框架一樣，Spring Security的功能圍繞身份驗證和授權。它可以與無Spring的應用程式以及基於Spring的應用程式一起使用。這主要是因為與Apache Shiro一樣，Spring Security與容器無關。

Spring Security的建立始於2003年下半年，當時是一個名為“ Spring Acegi Security System”的專案，當時是一個簡單的實現，最初並未釋出。隨著越來越多的Spring社群成員要求提供安全功能，他們獲得了上述專案。2004年初，大約有20個人在使用該專案。越來越多的人加入，最終在2004年3月建立了SourceForge專案。2006年5月，Acegi成為Spring的正式子專案，在2007年，它成為Spring Portfolio的一部分，並更名為“ Spring Security”。

測試環境

該框架是一個簡單的測試Web的應用程式組成的的REST API和一個index.html（也：登入/登出/的error.html）在開發Eclipse的霓虹燈對Java EE與WildFly 10.1.0.Final作為應用伺服器和PostgreSQL 9.6的永續性。

框架的配置儘可能以宣告式進行。

比較方式

請注意，這是這三個框架之間的相對比較。

Java EE安全性文件絕對是最基礎的文件，因為它不僅說明了如何使用安全性功能，而且還花了一些時間（而且篇幅較長，篇幅較長）來解釋基本的應用程式安全性概念。大多數其他框架都遵循文件中列出的安全模型，因此即使您不打算實際使用API，也值得一讀，特別是對於初學者。但是，如果您想快速入門，則可能需要尋找更簡潔的方法。

與其他兩個相比，Apache Shiro的文件介於兩者之間。它確實解釋了一些基本術語和定義，以及Shiro本身的工作方式或可以用它完成的大部分工作。但是，請注意它被稱為“大多數”，而不是“全部”，因為您可能會遇到一些空的“ TODO”部分。

使用方便

對於使用宣告式樣式的非常基本的配置，這三者都同樣容易，其中Shiro處於領先地位，而Java EE Security則處於落後地位，而Spring Security處於中間位置。

Apache Shiro示例

Shiro的宣告式配置風格真正令人感到滿意的是它的光滑度（甚至 看起來不錯）和簡單。您將配置寫入一個簡單的INI檔案中。XML僅用於啟用Shiro本身。

這是您的shiro.ini外觀：

[main]

# login / logout configuration | authc = shiro standard FormAuthenticationFilter

authc.loginUrl = /login.html # specifying which URL to redirect to, when Shiro attempts to authenticate a user via authc

authc.successUrl = /index.html # the redirect-URL after a successful login

logout.redirectUrl = /logout.html # the redirect-URL after a successful logout

[users]

# define some test users

jan = passwort, employer # format: username = password[, role1[, role2[, roleN]]]

naj = passwort, employee

ajn = passwort

[roles]

# define permissions for roles

employer = * # granted all permissions

employee = shop:browse:* # granted permission to browse the shop and do any related action

[urls]

# protect urls

/login.html = authc # this step is necessary to register /login.html as the loginUrl of the authc filter

/index.html = authc # catch requests to /index.html and let the authc filter process them

/ = authc # same as above

# specify logout url

/logout = logout # catch requests to /logout and let the logout filter process them

# REST urls | noSessionCreation is used to avoid creation of sessions | authcBasic = shiro"s standard BasicHttpAuthenticationFilter

/rest/shop/browse/** = noSessionCreation, authcBasic, perms["shop:browse:*"] # the perms filter additionally checks the subject for the specified permissions

/rest/shop/add = noSessionCreation, authcBasic, roles[employer] # the roles filter checks the subject for the specified roles

/rest/shop/delete/* = noSessionCreation, authcBasic, roles[employer]

Java EE安全性示例

相比之下，透過web.xml配置Java EE Security有點累。但是，最大的缺點是僅憑web.xml不能滿足要求。您還必須配置您的應用程式伺服器。當嘗試實現更高階的功能（例如JDBC領域）時，這可能會令人感到沮喪。

請注意，除了/index.html外，沒有其他受保護的URL。REST URL使用註解進行保護，在這種情況下，這樣做較為容易。幾乎快要看到胖的<security-constraint>元素了嗎？與shiro.ini相比，您比實際規則更忙於編寫元素名稱。對於小型應用程式，這似乎並不重要，因為您可以指定多個<url-pattern>。但是想象一下，編寫具有更多角色和規則來實施和保護URL的程式碼。

例：

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns="http://xmlns.jcp.org/xml/ns/javaee"

xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"

version="3.1">

<display-name>PetShop</display-name>

<welcome-file-list>

<welcome-file>index.html</welcome-file>

</welcome-file-list>

<servlet>

<servlet-name>Logout</servlet-name>

<servlet-class>src.servlet.Logout</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>Logout</servlet-name>

<url-pattern>/logout</url-pattern>

</servlet-mapping>

<context-param>

<param-value>true</param-value>

</context-param>

<form-login-page>/login.html</form-login-page>

<form-error-page>/error.html</form-error-page>

</form-login-config>

</login-config>

<web-resource-name>Some name</web-resource-name>

</web-resource-collection>

<role-name>employer</role-name>

<role-name>employee</role-name>

</auth-constraint>

</security-constraint>

<role-name>employer</role-name>

</security-role>

<security-role>

<role-name>employee</role-name>

</security-role>

</web-app>

Spring安全示例

Spring Security的基本配置非常簡單。它甚至可能比Shiro的要容易一些。它將建立一個登入頁面（如果您沒有登入頁面），並新增針對CSRF和會話固定的保護。不過，自動保護最適合JSP。對於HTML，變通辦法將是必需的。

要實現自定義元件，您將必須學習XML中的bean定義以及Spring的注入。這可能會導致大量的bean宣告，從而使.xml難以閱讀。另外，使用批註還需要進一步的Spring或AspectJ依賴性。

例：

<beans:beans xmlns="http://www.springframework.org/schema/security"

xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd

http://www.springframework.org/schema/security

http://www.springframework.org/schema/security/spring-security.xsd">

</http>

<form-login login-page="/login.jsp" default-target-url="/index.jsp"

</http>

<user name="jan" password="passwort" authorities="ROLE_EMPLOYER" />

<user name="naj" password="passwort" authorities="ROLE_EMPLOYEE" />

</user-service>

</authentication-provider>

</authentication-manager>

</beans:beans>

社群支援

這裡沒有太多要說的，因為與其他兩個相比，Spring Security具有龐大的社群。關於Spring Security的Stack Overflow（SO）有很多問題和答案，因此最有可能至少找到一些問題的提示。此外，不再支援官方論壇，它們僅在閱讀模式下可用。支援已移至SO。在那裡，國防部監視某些標籤。

對Shiro的支援相當“不錯”。有一個官方使用者論壇，活動活躍。在其他資源上尋求幫助不會產生更多的結果。您可能會看到相同的人（例如原始開發人員Lez Hazelwood）在受歡迎的網站（例如SO）上回答問題，這不一定是不好的。解決意外問題可能需要一些時間。

關於Java EE安全性支援的最糟糕的事情是，您還必須依賴於所使用容器的社群。因此，解決問題所需的支援，精力和時間會有所不同。

但是，這三個都在積極發展中。儘管Java EE Security透過Soteria API（Java EE 8）獲得了新功能，但Spring Security和Shiro仍在不斷改進。

特色功能

Shiro的簡單性和靈活性令人讚歎。INI配置進一步強調了這一點。Shiro還建議儘可能獨立於其他技術。它還需要很少的依賴關係，使其輕量級。非Web應用程式（例如CLI客戶端或移動應用程式）的會話管理和萬用字元許可語法也很重要。

Spring Security的自動保護機制使它在Web應用程式的上下文中具有最初的優勢。總的來說，可以說該框架在網路方面是相對全面的。但是，這是以犧牲自己的體重為代價的，並且在某些情況下必須繫結到Spring技術。與Shiro的萬用字元許可權語法相反，Spring Security中的許可權可以基於Spring EL來實現。

此處缺少Java EE安全性。換句話說，它確實不提供任何出色的功能，僅滿足應用程式安全性的最基本需求。

結論

如果您的應用程式非常小，使用者和角色沒有太多，並且不需要使用任何過於高階的功能，請隨時使用Java EE Security。為此，它提供了堅實的基礎。但是，Java EE安全性的可能性很快就被耗盡了。例如，您只能為整個應用程式指定一種身份驗證機制。另外，如果應用程式需要可移植，則一定要使用其他兩個框架之一。

現在，如果需要一個很大程度上獨立的，輕量級的和可擴充套件的安全解決方案，那麼Apache Shiro是必經之路。但是，不利的一面是可能需要花費一些時間才能解決問題。一個人可能還必須自己實現一些功能。Shiro的設計（基於介面的驅動和基於POJO的）促進了這一點。

最後，如果該應用程式已經基於Spring，那麼不妨繼續使用Spring Security，在這種情況下沒有任何實際的缺點（除了Spring Security難以實現）。對於沒有彈簧的應用程式，這是不同的，即使以前從未使用過Spring，也是如此。首先，更難實現高階功能，除非包含Spring本身或AspectJ，否則不能使用註釋。另外，如果需要Spring OAuth2，則必須使用spring-mvc而不是Jersey或RESTeasy來建立REST資源。

至此，我們的比較結束了。再次提醒我們有關觀測的相對性。自己嘗試框架，並使用最適合您需求的框架。

我不明白為啥選型都shrio，用著springboot全家桶…直接security多好，一系列的產品，沒毛病…就為了一個輕量級？

這麼說，shiro有的security都有，反過來不一定，但是shiro該有的也有，殺雞隻要割一個小口子，不用把雞頭砍掉