用ASP.NET Core 2.1 建立規范的 REST API -- 保護API和其它

本文介紹如何保護API，無需看前邊文章也能明白吧。

預備知識: 

http://www.cnblogs.com/cgzl/p/9010978.html

http://www.cnblogs.com/cgzl/p/9019314.html

建立成熟度2級的 API請看這里：

https://www.cnblogs.com/cgzl/p/9047626.html 

https://www.cnblogs.com/cgzl/p/9080960.html 

https://www.cnblogs.com/cgzl/p/9117448.html

HATEOAS：https://www.cnblogs.com/cgzl/p/9153749.html

緩存和並發: https://www.cnblogs.com/cgzl/p/9165388.html

保護API和其它: https://www.cnblogs.com/cgzl/p/9172603.html

 

本文所需項目代碼(右鍵另存, 后綴改為zip): https://images2018.cnblogs.com/blog/986268/201806/986268-20180612151833673-1851218969.jpg

認證和授權

認證/身份驗證 Authentication, 是驗證想要訪問特定資源的人/系統的身份的過程.

授權 Authorization, 是確認已認證的用戶擁有足夠的權限去做某些事的過程.

打個比喻: 認證是一個人可以進入到房間的權限, 而授權則表明這個人可以在房間內做哪些事.

 

認證的過程可以和應用程序分開並且還可以被其它的服務使用, 但是授權的過程通常是針對某個應用程序, 不同的角色會擁有不同的權限.

 

HTTP協議提供了一個協商訪問被保護資源的機制, 下圖就是HTTP認證:

標准的認證流程開始於一個訪問服務器被保護資源的匿名請求, HTTP服務器隨后處理了該請求並決定拒絕讓它訪問被保護的資源, 因為該請求沒有憑據; 隨后HTTP Server發送了一個WWW-Authenticate Header回去, 這表示它需要這套認證方案. 然后客戶端再次發送請求的時候包含了一個Authorization Header, 它的值符合HTTP Server的認證方案. 當服務器收到這次請求時, 它驗證了Authorization Header里的憑據, 並讓請求通過了管道.

服務器可以提供多種認證方案, 客戶端只需選擇其中一種即可, 上圖中使用的是Basic 認證方案. 還有其它的認證方案:

• 匿名 Anonymous 也可以當作是一種方案吧, 就當作是授權給所有人好了
• Basic 認證方案, 它是一種比較老的方案, n年前經常被使用. 它太簡單了, 它的值是含有用戶名和密碼組成的字符串, 並用冒號(:)連接, 並且編碼為Base64字符串. 例如username為dave, 密碼為1234, 那么Authorization Header的值就是: Authorization: Basic ZGF2ZToxMjM0.
• Digest 認證方案, 它作為Basic的代替者出現的. 服務器會給客戶端發送一個隨機字符串作為一個challenge(盤問, 質疑, 挑戰), 這個隨機字符串叫做nonce(可以理解為臨時生成的字符串). 而客戶端通過發送一個帶有用戶名, 密碼, nonce和其它信息的hash來進行認證.
• Bear 認證方案, 它是最流行也是更安全的認證方案. 它使用Bearer Tokens (承載令牌) 來訪問由OAuth 2.0協議保護的資源. 任何擁有bearer token的人都可以訪問相關的資源. bearer token的生命周期通常很短, 會過期. 例子: Authorization: Bearer: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c.
• NTLM認證方案, 它是NTLAN Manager的縮寫, 它是一種挑戰--響應的方案, 要比Digest更安全. 這種方案使用Windows憑據來轉化盤問的數據, 而不是使用編碼的憑據.
• Negotiate 認證方案, 它會自動選擇NTLM方案和Kerberos協議中的一個, Kerboros協議比NTLM快.

后兩種方案都僅限於Windows系統.

這幾種方案里Basic提供的保護程度/級別最低, 而Negotiate最高/強.

ASP.NET Core可選擇的認證提供商就很多了, 例如ASP.NET Core Identity. 但是它主要用於包含頁面的web應用, 例如MVC或Razor Page, 並不適用於REST/Web API, 所以不介紹它了.

如果應用部署在雲上, 可以使用Azure Active Directory(AAD) 和 Azure Active Directory B2C (Azure AD B2C). 我沒用過, 就不介紹了.

第三方的認證提供商有很多: AspNet.Security.OpenIdConnect.Server(ASOS), IdentityServer4, OpenIddict, Pwdless.....

我一直在用Identity Server 4, 但是這里不會深入介紹, 這里主要介紹如何實現REST API, 如果有需要的話, 可以寫一系列關於Identity Server 4的文章.

 

選項很多, 但是要實現的話還需要了解JSON Web Tokens (JWT), 它是一個基於JSON的開放工業標准, 它用於為雙方表示一些聲明. 它提供了一種緊湊的, 自包含的方式在雙方之間用JSON對象來傳輸信息.

JWT使用 HMAC secret 或 RAS公有和私有鍵對(key pair) 這兩種方式來進行簽名.

JWT由三部分組成: header, payload, signature. 形式如下面的偽代碼: [X=base64(header)].[Y=base64(payload)].[signature([X].[Y])] .

去這個網址可以更直觀的理解這三部分: jwt.io

JWT token最終是一個字符串, 它的三個部分用點(.)分開, 前兩部分(header payload)是Base64編碼的字符串; 最后一部分是前兩個Base64字符串的組合, 也是用點(.)分開並進行了簽名, 如下圖:

 

 使用Bearer方案和JWT的流程如下:

 

配置項目, 在Startup的ConfigureServices里:

如果使用Identity Server 4的話, 這里就可以不這樣寫了.

首先我們配置使用Bearer認證方案, 然后通過AddJwtBearer設定一些參數. Configuration里面的值可以放在appSettings.json里面或者其它地方:

然后在Configure方法里調用app.UseAuthentication()方法, 要在app.UseMvc()之前調用:

最后使用[Authorize]屬性標簽把CountryController保護起來, 也可以應用於Action級:

發送不帶Authorization Header的請求來測試:

返回 401 Unauthorized 未授權.

返回的Header里面告訴我們應該使用Bearer認證方案.

 

下面我們需要一個可以生成JWT token的節點, 針對本文我就在本項目里建立這個節點吧:

請求token的地址是 /api/authentication, 請求token用的是Basic方案, Post方法里就是先解碼, 驗證用戶名和密碼, 成功后調用GenerateToken生成token.

那就按要求再次發送請求:

注意這里usename:password的base64編碼是: dXNlcm5hbWU6cGFzc3dvcmQ=

現在我獲得了token, 然后我用token再次請求Country資源:

資源就可以正常的訪問了.

 

想要解析這個token, 需要到jwt.io:

箭頭處需要填上secret.

 

這個例子比較簡單, 實際應用中還是使用Identity Server 4之類的東西吧.

 

使用HTTPS

根據官方文檔(https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-2.1&tabs=visual-studio#require-https), 它建議ASP.NET Core web應用都應該調用HTTPS重定向中間件, 這樣就可以把所有的HTTP請求轉換為HTTPS.

只需要在Startup的Configure方法里調用UseHttpsRedirection()方法即可:

而在ConfigureServices方法里可以配置這個中間件:

 

HSTS (HTTP 嚴格的傳輸安全協議)

web應用通過使用特殊的響應header可以選擇使用加強的安全協議OWASP(Open Web Application Security Project), HSTS(HTTP Strict Transport Security). 當所支持的瀏覽器接收到這個header的時候, 瀏覽器就會阻止任何通過HTTP到指定域名的通信, 會使用HTTPS代替. 同時它也會阻止從瀏覽提的提示框點擊的HTTPS.

為實現這個只需要在Startup的Configure里使用:

 

 一般不建議在開發環境使用Hsts, 因為瀏覽器極有可能會緩存HSTS 的header. 默認情況下, UseHsts會排除本地回路的地址.

UseHsts會排除下列回路宿主:

• localhost : IPv4 回路地址.
• 127.0.0.1 : IPv4 回路地址.
• [::1] : IPv6 回路地址.

可以在ConfigureServices方法里對它進行配置:

這部分具體請查看文檔: https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-2.1&tabs=visual-studio#http-strict-transport-security-protocol-hsts

 

CORS 跨域請求

配置注冊CORS需要在Startup的ConfigureServices方法完成:

針對整個應用啟用CORS需要在Configure方法里調用下面的方法:

應該盡早的調用該方法, 以便在它后邊注冊的節點都可以被跨域訪問.

這是第一種方法, 使用的是lambda表達式.

注意URL地址結尾不要有/, 它會引起錯誤.

這種方法使用的是CorsPolicyBuilder 類, 它擁有Fluent API, 可以串接方法調用:

 

第二種方法是使用策略.

在ConfigureServices里配置好命名的策略:

在Configure方法里使用該策略:

另外也可以不適用UseCors(), 而是在下面這幾種級別指定使用該策略:

Action級別:

Controller級別:

全局Controller級別:

這么用的話, 需要禁用CORS策略就:

 

關於CORS的具體配置, 還是請參考官方文檔: https://docs.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-2.1

 

Rate Limiting 速率限制

速率限制是指限制被允許的請求到API（或某個特定的資源）。這樣就可以保護API，避免一些非正常使用的場景，例如網絡爬蟲或請求太多而導致API的性能嚴重下降，Dos和DDos。針對這點我們采取的節流策略是控制允許訪問API的請求的頻率/速率，它可以決定特定的請求是否被允許。

例如客戶端只允許每小時有100個請求到達API，也可以按天計算，還可以帶着IP地址一起限制。

響應的Header可以用來表示速率限制，但是這些Header並不是HTTP標准。這些header都以X-Rate-Limit開頭。

• X-Rate-Limit-Limit, 這個表示添加了限制並包含了限制的有效期。
• X-Rate-Limit-Remaining，表示該客戶還剩下多少個被允許的請求。
• X-Rate-Limit-Reset，提供關於何時限制會被重置的時間信息。

如果達到限制了，這些響應會返回429 Too many requests 狀態碼。有可能會包含一個Retry-After 響應Header，而響應的body應該包含解釋當前狀態的細節信息。當然這都是理論上要求的。

 

下面去實現，首先安裝這個庫 AspNetCoreRateLimit (https://github.com/stefanprodan/AspNetCoreRateLimit)：

首先在Startup的ConfigureServices里面注冊，用到了MemoryCache：

這里配置的是IP限制，它允許有很多規則，這里我只用了一個：針對所有的資源，每5分鍾最多3次請求。

現在，我需要注冊一個策略存儲和速率限制計數器的存儲，這兩個是被中間件使用。所以還需要注冊這兩個服務：

這里都使用的是Singleton單例，因為我們需要的是針對全局的請求來做操作。

接下來要在管道里添加中間件，它應該放在靠前的位置，在日志和異常之后：

 

測試，發送一個請求看結果：

可以看到5分鍾內還剩下兩次請求的配額。限制重置的時間大約在5分鍾之后。

發送請求超限之后，就會返回429：

Retry-After提示了再過294秒后可以再試試。。。

而響應的body是這樣提示的：

 

我們再組合幾個其它的規則：

現在允許5分鍾10次請求，但是每10秒鍾最多只能有兩次請求。

第一次請求后：

5分鍾內還剩9次，然后我10秒內連續發送兩次請求，然后再發送一次請求：

這時超出了限制，Header里：

提示6秒后可以重試, 6秒后再次發送請求：

 

這個庫還是挺靈活強大的，更多功能還需要看官方文檔。

 

API 文檔

業界通常會使用Swagger OpenAPI來對RESTful API進行格式化描述，而Swagger OpenAPI的當前版本是v3.

ASP.NET Core有一個第三方庫Swashbuckle，它支持Swagger，但是只支持版本2，版本2有個重要的缺陷就是不支持Action重載，之前HATEOAS的文章里提到過我們需要使用這種重載。所以Swashbuckle暫時並不是完全合適，所以我就不裝它了。

就暫時不弄自動文檔了。。。

 

單元測試

需要使用到xUnit和Moq，這里不介紹了。

關於xUnit，我寫過幾篇文章，有興趣可以參考下：

http://www.cnblogs.com/cgzl/p/8283610.html

http://www.cnblogs.com/cgzl/p/8287588.html

http://www.cnblogs.com/cgzl/p/8438019.html

http://www.cnblogs.com/cgzl/p/8444423.html

 

Moq的文章博客園應該有，如果需要的話，我可以寫一下。

 

其它

其它可能需要了解的包括：POSTMAN/Newman自動化測試，CI，CD，GraphQL等等。我就不介紹了

 

這個系列文章就到這了。

源碼（我還需要整理一下源碼，現在有點亂）：https://github.com/solenovex/ASP.NET-Core-2.0-RESTful-API-Tutorial