.NET Walker

這一篇很特別，我們要來談談 asp.net (.net core) 的身分驗證類型與基本原理(架構)。 最近這幾年，你可以從網站上找到任何你想找的資訊，特別是程式碼片段，但我總是眼睜睜的看著學員或客戶，從莫名的網路上抄來一份代碼，試著崁入自己的程式，無奈就是怎麼塞都塞不進去，不然就是硬塞進去之後，運行起來不如預期。 原因很簡單，因為硬Copy過來別人寫的東西，我們往往可能根本不知道那段程式碼寫的是什麼，只能硬插，無從改起。 這種狀況這幾年看了不少，身分驗證的部分更加明顯，有同學在寫WebAPI，但卻想用登入畫面去驗證呼叫者身分(!?)，有人明明在寫MVC，卻一直在研究怎麼用JWT Token登入…細問同學為什麼要這麼做? 答案總是很有意思。 所以，一直想寫篇文章，來釐清一下這些東西。 asp.net 網站的身分驗證(保存)類型 asp.net 不管是哪一個版本，不管是 .net framework 或是 .net core，本質上都是一樣的。大部分情境下(這世界總有特例，文章也總是有背景，我們討論的是『大部分』情境下，若有特例，請讀者自行轉換)，伺服器端保留(維持、識別) 用戶身分的機制大概有底下幾種： asp.net的Session變數 aps.net Cookies 驗證 Token (最近好像很流行 JWT) 首先，你必須知道一個前提，所有的Web應用程式和網路上伺服器和用戶端(瀏覽器)之間的交互(資料傳遞、呼叫)行為，本質上都是無狀態的(stateless)，也就是說，你不能假設伺服器端知道用戶是誰，或是伺服器端連續兩次的呼叫是不是由同一位用戶觸發的。 這點跟你的經驗可能不符，你會覺得，網站(伺服器端)知道你是誰啊?不然用戶幹嘛登入? 登入後伺服器端不就知道用戶是誰了嗎? 對，許多的網站都能夠登入，如果是無狀態，那登入怎麼實現的? 好，實現的方式大多是底下這樣，在伺服器端與用戶端溝通(互動)的過程中，會在 http message(大多是header)中，夾帶著一個記號，這個記號具有唯一性，每一個用戶都不同，這個記號隨著網頁每次的來回傳遞(或是WebAPI的被呼叫)，被夾帶在訊息(http message)之間，因此可以讓伺服器端知道當前的用戶端是哪一位。(這個記號大多只是一組ID，用來讓伺服器端識別用戶端，而非在記號

關於 .net core的登入與身分驗證方式 前情提要… 前幾天，我們示範了如何在 .net core 環境下，使用 cookie-based authentication 來實現登入與身分驗證功能。這個做法是從 .net framework以來就有的，也是延續到 .net core 最簡單且輕量級的身分驗證(登入)方式。 整個作法的影片在底下: https://youtu.be/ag9vQX9GAPs 當然， ASP.NET Core和 ASP.NET Framework 一樣，另外還有一整套 ASP.NET Core Identity機制，這套機制非常完整，除了基本的身分驗證，還包含權限管理、角色(Role)、Token、電子郵件驗證、忘記密碼…etc. 功能繁多。但當然也笨重很多。對於資料庫和身分管理邏輯也有一定程度的相依性。 也因此，我自己比較喜歡 cookie-based authentication 的簡單方法。 而採用了 cookie-based authentication 後的網站，可以透過 C# 後端程式碼，以很簡單的方式透過底下這樣的指令： User . Identity . Name 就可以抓取到當前登入的用戶名稱。詳細的做法，在上面的影片中我們已經初步的介紹了。 cookie-based authentication 搭配 Google 登入 接著，有讀者問到了OAuth的驗證整合，最常見的就是Google 登入。Google登入是什麼呢? 你會看到最近很多網站，都採用Google帳密登入，而非使用網站自己的帳密(也或許是兩者同時)。 所謂的Google 登入驗證，是一種SSO(Single-Sign On)登入機制，採用的其實是一套業界標準的OAuth機制，除了Google以外，Microsoft、Twitter、LINE都有利用這個標準做出了自己的登入功能。相關的說明您可以參考筆者 之前 的介紹。採用這個機制時，網站不需要知道用戶的Google帳密，只需要把身分驗證這一段，丟給Google去作，作完後把結果以Token回傳給網站。 透過Google SSO登入之後，我們可以取得用戶的Token，藉由Token取得用戶的身分(email)，接著，再利用前面介紹過的cookie-based authenti