backend security

OpenIDConnect WIP

ASPNET安全庫

• 簡化的ASPNET安全庫。
• 從頭開始重寫ASPNET安全庫。
• “光”功能風格的庫[90％無OOP]。

安全庫

• 身份驗證。
• authentication.facebook。
• authentication.google。
• authentication.twitter。
• 身份驗證。
• authentication.oauth2。
• authentication.openidconnect。
• 授權。
• dataprotection。

設計

• 安全服務[身份驗證和授權服務]代表機制骨幹。
• 安全服務[高級功能]充當安全行為控制器並代表公共API。
• 安全庫是按照FP原則[純函數，高階功能，不變性，數據/行為分離，靜態方法/函數作為一流公民的結果，結果模式]編寫的。
• DI通常在功能安全服務上用作薄層[例如。 SigninCookie具有2個實施，具有/不使用DI服務]。 DI服務實現像往常一樣使用特定的方法擴展[例如。 AddCookiesservices ， AddFaceBookServices ]。
• 安全機制基於安全服務[身份驗證方案自由機制]：
  • 身份驗證中間件接收身份驗證服務作為param [ Useephentication Extension]。
  • 授權中間件接收挑戰和禁止服務作為參數[ USEAUTHORIZIADENT擴展]。
  • OAuth回調端點以param [例如。 Mapfacebook ]。
• 身份驗證庫實施特定的身份驗證服務[例如。 AuthenticateCookie ， Signincookie ，挑戰Google ， AuthenticateFacebook ]。
• 授權庫實施授權服務[例如。授權]。
• 高級功能通常使用聲明樣式[例如。 Signincookie ]。
  • 通常不純淨的功能[具有副作用]。
  • 建立在低級和中級功能之上。
• 中級功能使用命令/聲明樣式[例如。 setAuthorizationParams ]。
• 低級功能通常使用命令式風格，並且是單線[例如。 ISSECUREDCOOKIE ]。
  • 通常，純[無副作用]或半色函數[對參數的副作用]。
• 高層中級級別的層次結構設計，我將其命名為樂高原則。它也可以看作是在基礎低級函數上具有具有的函數金字塔。
• 沒有其他策略[0（零）其他分支]。

過程

• 有兩個不同的安全過程：本地身份驗證和遠程身份驗證。
• 本地身份驗證過程[cookie]：
  • 每個請求[使用身份驗證中間軟件]調用身份驗證函數[例如。 AuthenticateCookie ]。基於身份驗證結果，中間件集httpcontext.user prop。
  • 然後每個請求[使用授權中間軟件]調用授權函數[例如。授權]。根據授權政策的結果，確定是否允許請求，未經驗證/挑戰或未經授權/禁止。
  • 符號/簽名彈性用於開發的特定端點/控制器操作。
• 遠程身份驗證過程[OAUTH2協議]：
  • 當被調用時，挑戰端點[例如。在Mapfacebook上註冊]構建並將授權請求發送到授權服務器。
  • 處理授權請求後，授權服務器將響應重定向到回調端點[例如。在Mapfacebook上註冊]。該端點接收授權服務器響應並調用回調func [例如。 callbackfacebook ， callbackoauth ]。回調功能有2個步驟：
    • 身份驗證： AuthenticateOauth Oauth身份驗證功能具有3個取代：
      • 授權後- 驗證授權代碼和授權服務器的請求[local]。
      • ExchangeCodeFortokens-與授權服務器交換訪問[和刷新]令牌[遠程]的授權代碼。
      • AccessuserInfo-使用訪問令牌從授權服務器獲取用戶信息[遠程]。
      • 身份驗證步驟將從授權服務器收到的用戶信息轉換為安全索賠，將其添加到索賠身份，創建身份驗證票證並返回AuthenticationResult 。
    • SIGNIN：在認可驗證後，在OAuth身份驗證步驟之後，然後稱為符號func [例如。 *Siginincookie^， SignInBearerToken ]。 Signin Func設置在OAuth端點註冊上。
  • 回調重定向後，下一個請求將使用本地身份驗證過程。

評論

• 完全重寫身份驗證機制。
• 部分重寫的授權機制[與ASPNET授權政策機制保持兼容性]。
• Cookie身份驗證服務通過手術實現基於會話的Cookie功能[使用IssessionBasedCookie Func]。身份驗證，簽名和簽名服務是完全獨立的[對HTTPContext功能沒有依賴性]。 AuthEnticationSessionCookie ， SigninSessionCookie和IndoutsessionCookie會話cookie服務與非課程的版本完全隔離。
• 身份驗證選項實現僅包含數據[例如。 cookiuthenticationAption ]。 Cookie身份驗證服務[非基於DI的服務]將所有依賴項作為參數接收。
• Microsoft ASPNET身份驗證選項實現包含數據和行為/服務[例如。 Sessionstore ， TicketDataFormat ，用於cookiuthenticationOptions的SystemClock ]。與我的實施相比，該設計具有一些優勢：
  • 與在DI上註冊的服務不同。
  • 通過身份驗證過程（減少參數的數量）來封裝和進行這些服務。
• AuthenticateOauth Oauth auth authentication func使用模板方法設計模式允許OAuth庫在必要的後置術， ExchangeCodeFortokens或訪問權限的身份驗證取代[eg。 AuthenTicatetWitter ， AuthenticateFacebook ]。
• 重定向的言論：
  • 挑戰和挑戰odoidc funcs重定向到授權服務器[挑戰oidc可以使用形式而不是重定向]。
  • CallbackoAuth和Callbackoidc funcs將重定向到原始URL，或者在回調身份驗證錯誤到AccessDeniedPath或ErryPath身份驗證選項Prop取決於錯誤類型。
  • signincookie ， signoutcookie ，挑戰*，禁止*等。沒有重定向[面向WebAPI的功能]。當重定向是必要的時，這些功能可以裝飾並重定向到authentication properties.redirecturi或authenticationOptions.turnurlarlparameter查詢參數。
• 餅乾說：
  • AuthenticationCookieOptions.expireSfter單個位置可以控制AuthenticationTicket [Cookie]持久性。
  • AuthenticationCookieOptions.Cookiename單個位置可控制cookie名稱。
• OIDC言論：
  • PKCE是有關授權代碼流安全性的推薦解決方案。
  • 基於OIDC的最佳實踐不支持隱式和混合流[甚至由OIDC RFC支持]。
  • NONCE不是必不可的，因為隱式和混合動力僅是所需的NONCE參數的流。

項目目標

• 解開ASPNET身份驗證/授權機制和本地/遠程流程的解開/神秘化。
• 簡化身份驗證/授權機制[基於ASPNET模式的免費機制]。
• 演示功能編程實現。
• 展示一個實用的OOP替代方案。

基準

方法	InvocationCount	意思是	錯誤	stddev	中位數	比率	比率	Gen0	Gen1	Gen2	分配	同種比率
fpsignin	128	64.34μs	1.196μs	1.119μs	64.69μs	1.00	0.00	-	-	-	7.96 kb	1.00
OOPSIGNIN	128	79.98μs	3.247μs	9.212μs	79.56μs	1.13	0.14	7.8125	7.8125	7.8125	116.21 kb	14.59
fpsignin	512	45.75μs	5.065μs	14.934μs	39.12μs	1.00	0.00	1.9531	-	-	7.96 kb	1.00
OOPSIGNIN	512	97.08μs	7.432μs	21.679μs	95.52μs	2.41	1.12	9.7656	9.7656	9.7656	445.7 kb	56.01
fpsignin	1024	28.83μs	2.009μs	5.533μs	26.26μs	1.00	0.00	1.9531	-	-	7.95 kb	1.00
OOPSIGNIN	1024	186.15μs	26.776μs	78.949μs	211.04μs	6.32	3.02	14.6484	13.6719	13.6719	915.64 kb	115.12

• 對於InvocationCount> 2048 OOP基准開始運行非常慢。