.NET Walker

現在的應用程式登入，特別是 Microsoft, Google, Facebook等大廠的網站SSO登入，常常設計有二階段驗證(2FA)，而其中手機App二階段驗證是最常用的模式。主要是因為簡單、迅速、免費，對於用戶、開發人員、網站本身，都是一個很好的選擇。 這種透過手機App實現的二階段驗證，採用的常是一種稱為TOTP(Time-based One Time Password)的技術。簡單的說就是，用戶以先以正確的帳號密碼登入之後，必要時(或每次)再跳出一個驗證視窗，讓用戶輸入另一組隨機產生的N位數密碼，而該密碼會自動出現在你的手機(APP)上，且只能使用一次並有時間限制。 如此一來，即便用戶的帳號密碼不慎外洩，駭客也必須要有用戶的手機，才能登入或執行進階的功能。當然，如果每次都要這樣驗證，用戶肯定會覺得麻煩，所以這類的驗證，往往不會在每次登入時都進行，而是在底下幾種情境下被觸發： 用戶在不尋常的情境下(地區、IP、時間)登入 用戶要進行進階的行為(例如變更密碼) 觸發的時機或演算法因系統特性不同而異，但2FA做法的原理則大致相同，這一篇，我們就來看如何實現2FA。 概念 上圖是 Twilio 網站的 TOTP示意圖，現在有很多業者提供 Authenticator App來實現這個功能，我自己喜歡 Twilio 的 Authy Authenticator, 你可以從底下位置下載： https://authy.com/download/ 使用 Authenticator App 實現2FA 的典型流程如下: 網站針對已登入的用戶產生一個唯一的key值，並以這個Key值產生URL，進而生成QR Code 讓用戶以任何一款Authenticator App掃描該 QR Code，即可在該App上登記註冊。 掃描好QR Code完成註冊後，一般會先做一次六位數密碼驗證，以便於確認用戶有正確完成掃描註冊。 未來，任何需要二階段驗證的時機，網站後台都可以呼叫API產生六位數密碼，並讓用戶在手機上檢視由App產生的六位數密碼，若兩者相同，即可確認用戶身分正確無誤。 實作 程式碼其實一點都不難，而且有現成的NuGet套件可以使用，我整理好的 source code 這邊: https://github.com/isdaviddong/...

Azure API Management ( APIM ) 是 Microsoft Azure 服務的一部分，主要功能在協助組織建立、發佈、維護、監控和保護 API。 其主要功能包含： API Gateway 限流和配額 分析和監控 保護 API 現有服務的代理和包裝 … 使用 Azure APIM 可以幫助組織提供統一的 API Gateway、提升 API 管理與發佈、更確保 API 的安全和可靠性。因此，在最近幾年許多企業開始想走微服務或是API first的架構下，常常做為API的對外閘道。 這樣做有一個好處，拿保護API做為例子，透過APIM，你只需要透過設定，就可以讓Gateway 後面的所有API都支援 JWT token驗證，你就無需在每隻API的程式碼裡面，去做token驗證的動作。 這一篇，我們就來實踐這個例子。 使用 Policy 我們做好了一組測試API，呼叫的網址是 https://testapim20231030.azure-api.net/conference/speakers ，這是APIM的雲端位置，它保護了我們原始的API Endpoint，這也是閘道器基本的功能和行為。 你會發現，預設狀況下我們透過postman在呼叫這組API的時候，是無需驗證帳號密碼的： 假設，我們希望讓 APIs 都受到JWT token驗證的保護，那只需要在 InBound Policy 這邊做設定： 加入底下這條 policy: <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized"> <issuer-signing-keys> <key>123456781234567812345678</key> </issuer-signing-keys> <required-claims> <claim name="admin...

在Web應用程式開發的過程中，我們常常會聽到所謂的 Claim-Based Authentication或Authorization之類似的用詞，中文常直白的翻成『基於聲明的驗證或授權』。 翻譯沒錯，但『基於聲明的…』中的這個『聲明(Claim)』，有點不好理解。 簡單的說，你可以暫時先把所謂的『聲明(Claim)』理解成一張駕駛執照(或身分證)，由監理單位(或戶政單位)發出，發出Claim的單位我們叫 Issuer。 在傳統的 asp.net core web應用程式當中，身分驗證與授權(authentication and authorization)，預設常常都是走 Claim-Based 來實踐的。其實應該說，當我們進入了WEB 2.0時代之後，網站開始需要與用戶端互動，伺服器端需要識別用戶是誰，並針對不同的用戶給予不同的權限，這時，基於聲明的Claim-Based Identity就逐漸成為主流。 在解釋之前，先簡單提一下驗證(authentication)和授權(authorization)，一般來說，『驗證』是確定你是誰(who)，而『授權』則是確定你能做(或能看、能存取)什麼(What)。 為了實現這件事情，一般的網站在開發時，大致會這麼做： 用戶在使用某個網站時，會先透過瀏覽器以匿名方式進到一個登入頁面。進入該頁面後，會先以帳號密碼(或是其他機制、例如email、SMS)進行登入(Login)工作，這就是驗證。通過驗證之後，網頁系統一般會建立一個由伺服器端發出的Claim，這個Claim就像我們剛才說的駕駛執照一樣，可能描述(聲明)著用戶的個人資訊，以及該用戶可以駕駛的車種(也就是權限之類的訊息)。為了確保安全，一般來說，Claim常會被編碼或加密，然後包裹成為一個Token，甚至加入一些檢核機制，以便於能夠確保該Claim(Token)的合法性(例如足以識別該Token是由誰Issue的)。接著，應用程式就可以拿著這個Token(或實作成cookie)，作為憑證來存取特定的資源。 以上這樣的機制，就是Claim-Based Identity。 你可能會覺得疑惑，那我們在開發 asp.net core 網站的時候，有這麼複雜嗎? 感覺好像沒有做那麼多步驟啊!? 其實有，只是 .net 框架主動為你做了大半，所以開發人員常常不知...