.NET Walker

過去，如果你有用 Azure OpenAI 開發對談機器人，其中最麻煩的事情之一，大概就是記錄和處理歷史對談訊息。但歷史對談訊息對於AI的正確回覆佔有舉足輕重的角色，不記錄不行。 這是因為本質上API的呼叫是無狀態的(Stateless) 因此，在與API交談的過程中，你每次呼叫API都必須把過去的訊息，當作參數重新傳到後端，這樣API後面的AI Model才會知道先前跟用戶說過了什麼。但如此一來，對談越多，不就得花費愈多Token嗎? 是的，沒錯，這是過去透過OpenAI開發對談機器人時的一個難題。 2023年11/06，OpenAI舉辦了DevDay，在keynote的場次中，Sam Altman介紹了新的API --> Assistants API，把對談機器人的開發，再繼續優化到更簡單的步驟。 搭配Assistants API，你可以輕易建立出一個智能助理(或客服機器人)，除了讓開發人員更省事之外，還包含了類似RAG的功能，可以將企業內的資訊先餵給這個AI助理。 如今，Azure OpenAI也提供了這個服務，在 美國東部2 、 澳大利亞東部 和 瑞典中部 率先提供了這個服務(Preview)，同樣的，他提供了一個遊樂場後台： 初次進入，畫面上出現『找不到任何佈署』? 那你就給他來個新的佈署： 系統會引導你建立一個獨立的模型: 接著就可以透過該模型來建立助理了： 填寫完智能助理的名稱、提示(system prompt) 之後，就可以儲存和測試了。 乍看之下，和原本的聊天對談沒什麼不同，但背後有一個很大的差異，那就是，過去的聊天對談，前後文(Context)的實踐是透過把先前與機器人的互動(訊息)，每次重新回傳給API來實現的，而現在這個助理(Assistant API)則是透過一個新的物件，叫做Thread(執行緒)，來保存這些對話記錄。簡單的說就是，你不用再自己保存對話記錄了： Thread(執行緒)聽起來有點抽象，你可以把一個執行緒想成一連串的對話記錄，其中有一則一則的訊息(Messages)： 當用戶輸入一則訊息(放上Thread)給機器人(assistant)，機器人回覆這則訊息(也放上Thread)，這樣就構成了一個Run。 也因此，透過 Assistant api 操作的對談流程，原則上大概是底下這...

先前介紹過 OpenAI API 的 DALL-E-3 ，但如果你要在Azure OpenAI 上使用相同的功能，不管是模型的佈署和API的呼叫，兩者之間都有些不同。 使用在Azure OpenAI上的DALL-E-3，你必須把服務建立在瑞典中部(Sweden Central)的資料中心，才能享用該模型: 目前只有該資料中心有提供 DALL-E-3 的模型選項，當你將AOAI的服務建立在Sweden Central資料中心，就會在模型佈署中，找到底下這個 dall-e-3 的選項： 如果你透過 Azure OpenAI Studio 這個後台測試 DALL-E，你會發現系統會自動幫你佈署 dalle3 模型： (動畫) 有了DALL-E-3模型之後，你就可以透過自然語言產生圖像了： 如果你要採用 API 來生成圖像，可以參考微軟 官網 上的 API 使用方式。 我們也可以透過 Postman 呼叫該 API： 台北 101 的下雪美景，就這樣出現了： 但你需要注意到，Auzre OpenAI DALL-E-3 的 API Endpoint 也明顯與Chat不同: https://{AOAI服務名稱}.openai.azure.com/openai/deployments/{Dalle3佈署名稱}/images/generations?api-version=2023-12-01-preview 不過掌握好了之後，透過程式碼來動態建立圖像，也就只是小菜一碟了。 相關課程： https://www.studyhost.tw/NewCourses/LineBot

時代在改變著。認證考試也是。 微軟推出全新的 Microsoft Applied Skills 系列的認證，現在主打免費、隨時隨地都可以考，而且是仿造真實世界的案例實作，也就是說，這是上機考試唷。 通過了，你會得到一個類似底下這樣的證書，證明你在特定領域具有實作能力： 考試時間共兩小時，算是充裕，前提是如果你對於考試的主題真的有足夠認識的話。 你一定以為，線上考試，那不就是可以open book? 應該很容易通過吧，並不一定。 考試是採用網頁進行，網頁中會出現一台可以遠端操作的虛擬機(類似WVD)，考生可以在網頁上透過實作，完成所有題目。 如同微軟一般的認證考試，作答完成送出之後，你會立刻看到結果： 如果你沒通過，會收到底下這樣的訊息： 可以重考嗎？ 可以，但要冷靜一下，７２小時之後才能繼續。 若是考過了，則會出現美麗的綠色畫面： 其實，我還蠻喜歡這個考試的。 首先，它免費。相較於其他認證考試，它不用錢也可以考，沒通過頂多等個72小時，用功一點很容易可以考到過為止。 比起是非、選擇這種考試，Applied Skills 是真的要操作的，這對於真正有在應用的技術人員而言，其實是比較有利的，有時候根本不用特別準備，就可以去考，考了就過。說實在的，就算你原本不會某個領域，能憑真本事通過，大概本來不會的實作完之後也搞清楚了。基本上這個考試的目的就是要你真的搞懂某個技術實作，因此，這考試算是很務實的。 隨時隨地都可以考。傳統認證需要報名、排隊、跑去考試中心、待在小房間裡面幾小時，還不能上廁所😆。但這個考試，你隨時，隨地，想到就考，像我大半夜睡不著，手邊沒劇可以看，索性考個認證，也算是挺有成就感的。 總的來說，這個認證考試挺好玩的。 硬底子的技術夥伴們，不妨無聊的時候考個兩張來玩玩。 瀏覽認證: https://learn.microsoft.com/zh-tw/credentials/browse/?credential_types=applied skills 常見問題: https://learn.microsoft.com/zh-tw/credentials/support/applied-skills-faq#applied-skills----------------

昨天去參加G社群舉辦的活動，想說來認識一下Gemini。 來到了據說是全台灣最高的活動舉辦場合，也具體實作了一下 Gemini API 的使用。 聆聽分享的過程當中，台上講者問大家說：『現在已經有使用 OpenAI API 的舉手? 』(恩…很多)。 又問：『現在已經在使用 Gemini 的呢?』(哇…也不少)。 再問：『那使用 Azure OpenAI 的呢?』 我正想舉手，往四周一看，哇靠，怎麼一個人都沒有! 真的假的? 原來來到不同的陣營，民調數據會差這麼多? 🤔 接著台上講者繼續問大家，用什麼語言寫AI程式，看來 Python 還是大宗，我本來想喊 C# 的，但看看周遭氛圍，我決定暫時先觀望一下。 然後講者開啟自己的 github repo，點選一個 badge ，把 github 的source code 帶到 colab 中，順口又問了一句：『應該大家都用過 colab 吧?』 (我本來又想喊…“沒有”) 沒想到講師立即說：『恩…很好，顯然大家都有用過…』😮😮😮 我偷偷看了一下隔壁的朋友，耶欸，大家好像還真的都挺熟悉colab的呢。哇，果然隔『營』如隔山。 接著我看講者嘩啦嘩啦地在colab中運行每一個程式碼片段，行雲流水，很是順暢。也難怪，大家喜歡用 python，雖然從我的角度來看，一直覺得它其實跟 Visual Basic 有點像。 不過做Labs的過程中，我確實也開始覺得，有寫好的互動式腳本，上課時還是頗方便，大家只需要點個按鈕 clone 過去，然後程式碼都寫好了，只要改改參數，就可以一段一段運行了，難怪大家覺得 OpenAI API 和 Gemini API 用起來很簡單。 但其實，Azure OpenAI 也不難啦~ 做完 Gemini Lab 後，我索幸順手也寫了一個 python 的 notebook ，用 python 來呼叫 Azure OpenAI ，我把它放在 github 上了。又效法講者的作法，為它做了一個 badge ，讓用戶可以從 github repo 直接連到 colab。操作動作如下： 然後我們就可以在 colab 中，透過互動式的方式，一段一段把程式運行完，體驗一下 Azure OpenAI API的呼叫。你看到上面的影片，就是整個操作過程。 由於notebook程...

最近重讀 Sam Newman的『建構微服務』，覺得實在精彩。真心以為，想作微服務系統的開發人員，都值得花點時間讀一下第一章，絕對值回票價。 我把讀完的感想和摘要寫在下面，希望能夠幫助大家釐清什麼是微服務(以及什麼不是)。 傳統來說，古典的單體式應用(Monolith)大多意指在同一個行程內運行的應用系統，底下是典型的單體式應用程式與其變形。 古典的單體應用程式 一個應用程式，後面搭配一套DB，但上面這樣的系統已經愈來愈少了，只剩下像是手機app或是極端傳統的desktop app。 如今大部分的單體式應用系統(不管是desktop或web)，大多會是底下這樣： 模組化單體式應用程式 模組採用同樣(或近乎類似)的開發技術。 模組間有共用的基礎設施(infrastructure)，像是log, security…etc. 即便模組可以獨立運行，但依舊必須一起佈署。 單體式應用系統的優點 相較於微服務，單體式應用系統其實有很多優點: 簡化開發人員工作流程 簡化監控、故障排除、與測試 這是事實，但Sam Newman強調『最近人們開始將單體式系統視為「時代遺產」的同義詞，仿佛這種系統有著什麼本質上的問題，是一個需要避免的東西…』 但其實，單體式架構只是一種選擇，甚至是一種有效的選擇。Sam Newman認為：『這是一個作為架構風格合理的 預設選項(我欣賞這句話) 』，換句話說，我也認為，面對架構選擇，人們應該尋找一個能被說服使用微服務的理由… 微服務架構 我們很久以前就談過微服務，但到底什麼是微服務? Sam Newman在書中，對微服務的核心概念做了說明，我覺得包含幾個重點: 可獨立佈署：微服務的每一個單元應該能夠單獨部署，而不需要依賴其他服務。這種可抽換性使得應用程式更加靈活，可以更快地部署和更容易地維護。這也意味著， 當你抽換一個微服務、另一個微服務不該受到影響。 圍繞著Business Domain塑模： 每個微服務都應該圍繞一個具體的Business Domain來設計，而不是根據技術或企業組織架構來劃分 。這種業務驅動的作法使得應用程序更加緊密地與業務相關，並能夠更好地支撐業務需求的變化。(這一點很多公司其實先天就無法做到，參考底下『架構和組織的調整』) 大小：微服務應該要足夠小，以便能夠單獨佈署和管理...

Cloud Shell是雲端的CLI環境，你可以從Azure Portal上直接啟動該環境： 這麼做的好處是，你即便在本機電腦(筆電)上沒有安裝AZ CLI，也可以透過網頁即可以命令列模式來管理雲端的資源。 另外，使用雲端版本的CLI還有一些額外的好處，諸如: 無須登入(az login…)，因為你使用Cloud Shell的時候，本來就有登入Azure Portal。 無須安裝其餘CLI工具或SDK，諸如 git, dotnet , python, docker, kubectl…這些內建通通都有。甚至，還有網頁(陽春)版的VS Code!!! 底下影片介紹如何操作Cloud Shell，第一次進入的時候，會讓你選擇一個Azure 儲存體(Storage)，並且選擇Linux或Windows環境: 所以，Cloud Shell內建就有Windows與Linux雙模式，你可以透過左上角的選項切換: 其實，Cloud Shell本身就是一個儲存體，你可以在該環境中建立資料夾，新增檔案，除非你刪除或無法存取該訂閱，否則這些資源都會保留在雲端儲存體中： 一般來說，如果要對雲端的Azure資源進行操作，我們常常會直接在Cloud Shell中，下CLI或Power Shell/Bash指令，省去在用戶端還需要安裝 CLI 並且做 az login 動作的麻煩。 有操作Azure的開發或維運人員，是一定得要試試看這個好工具的。

最近這幾年，愈來愈多的網站改以前後端完全分離的架構來開發，而微服務盛行，許多後端應用、AI服務、甚或是商業邏輯，都改以WebAPI的方式來實作，更別說為數眾多的手機行動裝置App也需要以呼叫後端API的方式與伺服器端溝通，來完成各種功能。 因此，API開發成為最近幾年的顯學，API First也在許多場合被提起。Azure的APIM服務，就在這樣的情況下誕生了。 使用APIM服務 Azure APIM可以幫我們把企業內部的多組API打散或重新包裝，改以同一個endpoint對外，好讓使用者更方便使用，讓管理者更方便控制與管理。 另外，採用APIM還有一個好處，我們可以隔開用戶和真正的API，這樣除了可以保護後端真正的API，也可以在用戶透過APIM呼叫後端真正的API前，可以對往來(與回覆)的數據做一些加工處理，已達成我們需要的安全性或是API行為的改變，也更容易統一的進行全縣控制…等。 建立APIM 底下影片示範如何建立APIM服務，請注意APIM服務的建立，會花比較長的時間，可能會長達半小時以上: 完成之後，就可以建立好APIM服務了。 建立API集合 建立好APIM服務之後，接著可以在Azure Portal中，建立API集合，前面說過，我們會把實際上開發好的API，先整理成API集合，然後再包裝成產品(Product)，釋出給客戶。 底下的說明，我們將示範如何將現有的API(在具備spec definition的狀況下)，整理成待會要釋出的產品。我們以底下這組微軟官方的測試API為例: https://conferenceapi.azurewebsites.net?format=json 如果你點選上面這個網址，會發現，它出現的是json格式的API規格: 這是標準的 swagger 2.0規則，一般我們撰寫WebAPI之類的後端API服務，都可以透過工具自動產生這些規格文件。若具備這些規格文件。 你可以直接將API透過Import的方式匯入，請看底下操作影片: 從上面的影片當中，你會看到，我們利用 swagger 的json規格定義，把上面的微軟測試API，重新透過APIM封裝，建立另出了一組 endpoint 。 你可以發現API中有一個 GetSpeakers 方法，當我們運行(呼叫)這個方法，會以JSON格式回傳...

什麼是非關聯式資料庫? 最近這幾年，非關聯式資料庫開始成為許多大型系統的架構考慮之一，原因有很多，但歸根究底核心原因我覺得是『全球化』。 過去企業(即便是大型的全球化企業)在建立資訊系統的時候，大部分都是以集中式為主的架構，也就是說，核心的資料庫只會有一份，頂多加上異地備援機制。 在傳統的企業營運需求上，這樣的設計完全沒問題，而且關聯式資料庫的特性就是 ACID ，有著結構清晰的資料表，經過正規化，存入的資料欄位都是固定的，這確保了資料的高可靠性與正確性，對企業應用系統來說，恰是所需。 但對於全球化的網際網路需求，可就不一定了。 當前的關聯式資料庫儲存資料有幾種類型，像是底下這樣: 你發現，這些資料的結構跟過去方方正正的資料表很是不同，現實生活中，有很多類似這樣的資料，例如: 若我們想表達一位用戶的朋友、資源、行事曆、檔案…等資訊，結構上就很可能不是傳統關聯式資料表所能表達的，這時候非關連式資料庫就開始派上用場。 除此之外，另外一個主因是 --『同步一致性』。 資料的同步問題 在企業內，資料的一致性似乎很重要，但一致性並非沒有代價，假設資料庫採分散式架構，在全球3-5個點都有資料庫，彼此之間進行同步抄寫。 這樣的架構底下，要維持一致性是很困難的，這也是大部分企業應用都採集中式架構的原因，但集中式架構最大的缺點是，如果總部斷線，就意味著全球各地區都別運作了。 但真實世界中，我們真的需要在全球有數個彼此同步抄寫的資料庫嗎? 過去沒有，但現在可能到處都是，最明顯的例子就是像FB之類的社群網站。 社群網站每秒中有數以萬計的留言對話，可能同時需要存入資料庫，如果採用傳統的關聯式資料庫，又是集中式設計，很可能根本無法運作，因為資料庫的loading太大了，光寫入資料就沒時間了，更何況還要承擔全球性的讀取。 所以非常有可能採用全球數個資料庫彼此抄寫的狀況，但這時候，『資料同步』將是個問題。 我鍵入一筆留言，在台灣的資料中心可以即時看到並回應，但在地球另一端的資料庫中卻可能還沒出現，因此我在國外的友人會隔一段時間才看到(需要等資料抄寫過去)，然後他才能回應，同樣的當國外的友人回應，在台灣的我可能也不會立刻看到，而會延遲一段時間。 這就是分散式資料庫可能會碰到的問題。 這對於開發人員來說，是兩難。因為 集中式效率會變低，分散式會導致資料的精確性或...

Cache被稱作快取或緩存，是一種提高運作效率的資料存取方式。 Redis Cache本身是一套open source軟體，以記憶體作為緩存資料的位置，我們可以把一些時常(或大量)需要被讀取，或是不常更新的靜態資料，從傳統資料庫(或其他儲存體)複製一份放入Cache DB中，以便於提高讀取時的效能。 因為資料庫或一般硬碟儲存體的讀寫是物理性的IO存取，而Redis Cache則是記憶體的讀取，當有大量的讀取發生時，位於記憶體的Redis Cache效能會明顯的比實體的讀取提高很多。 一般來說，典型的Cache機制使用方式如下: Cache中的資料可能會定時或依照你所設定的條件更新，以便於抓取較新版的資訊。 在Azure PaaS平台上，也有現成的Redis Cache服務，你可以透過底下CLI指令來建立Azure Redis Cache服務: #設定資料中心區域 $myLocation = "eastasia" #建立資源群組 az group create -n test-redisdemo-rg -l $myLocation #設定redis cache名稱(取亂數以避免重複) $redisname = "testredis" + $( get-random -minimum 10000 -maximum 100000 ) #建立redis cache az redis create -l $myLocation -g test-redisdemo-rg -n $redisname --sku Basic --vm-size c0 結果如下(回覆JSON): 當然，也可以透過底下網址，從Azure Portal建立Redis Cache: https://portal.azure.com/#create/Microsoft.Cache 建立畫面如下: 建立完成之後，基本的使用就很簡單，你只需要從Portal上找到 Redis服務的 ConnectionString(位於存取金鑰)，即可操作該Cache: 有了ConnectionString後，利用SDK，透過ConnectionMultiplexer.Connect()方法，即可存取該料庫: var cache ...

Storage Queue是相對Service Bus而言較為簡單便宜的queue解決方案，以Storage為儲存體，在Storage中就可以直接建立: 透過程式碼操作的方式也很簡單，先找到key: 接著透過SDK，建立一個QueueClient物件即可操作: public static void CreateQueueClient ( string queueName ) { // Get the connection string from app settings string connectionString = ConfigurationManager . AppSettings [ "StorageConnectionString" ] ; // Instantiate a QueueClient which will be used to create and manipulate the queue QueueClient queueClient = new QueueClient ( connectionString , queueName ) ; } 請注意上面的程式碼使用了 Azure.Storage.Queues 套件，因此你必須從nuget安裝: dotnet add package Azure.Storage.Queues 我在github上有一個範例，讀者可以在建立好queue之後，透過git clone下載該範例運行: git clone https://github.com/isdaviddong/az204-DemoAzureStorageQueue.git 運行的流程請看底下展示影片: 身為一個簡簡單單的FIFO容器，Queue看起來沒啥大錄用，不過就是放放資料讓資料排隊慢慢處理，但記得前面提過的 Load Leveling嗎: (from Microsoft architecture center) 如果用的好，Queue可以幫你省下大筆 做 scale out的經費呢，總有人覺得雲端貴，但其實，往往...

古時候的應用程式，大多是一座孤島，作業系統載入一個應用程式(例如計算薪資)，當它運行完畢，結束，就退出作業系統，釋放資源，把控制權交出來。當時的應用程式架構很簡單，就…把功能通通寫在一起，完畢。 時間快轉到今年，過去就表過不提，自從有了網路(特別是網際網路)之後，應用程式的架構開始愈來愈複雜。例如，現在很多Web應用程式是前後端分離的架構，後端採用Restful API，前端運行在瀏覽器上，透過javaScript(或某種js框架)，與後端Restful API互動，彼此交互以完成一個工作。 這是近代初學者，最常碰到的應用程式架構。 但當應用程式的功能愈來愈多，我們當然不可能(也不需要)在『一個』應用程式當中，一口氣去完成所有功能，我們可以把應用程式切小，然後透過應用程式和應用程式之間的合作，來完成一個比較大的任務，這時候，擔任應用程式與應用程式之間資訊傳遞橋梁的事件(event)和訊息(message)就顯得非常重要了。 事件(Event)和訊息(Message)的意義 在這一篇的討論當中，你看到的『事件』和『訊息』這兩個字眼，大多意味著某種資訊 --> 像是一組JSON資料、一個文檔、或是一個XML資訊、甚至，只是幾個bytes的字串。 總的來說，『事件和訊息』就是 應用程式A 傳遞給 應用程式B 的某種資訊，主要的用途是 溝通 。例如用戶在前端網頁上購物，產生了一筆訂單，這筆『訂單』就是一個訊息，Web的前台系統，會把這個訂單，傳遞給中台或後台的其他程式，來處理出貨、扣庫存、帳務處理…等動作(功能)。 你或許有一個疑問，為何不在前台網站系統用戶產生訂單的那一刻，就扣庫存和安排出貨呢? 技術上可以，但實務上常常不是這樣的。因為不是所有的系統都是一體的，企業的系統可能是分階段、分廠商開發的，甚至可能根本是外購不同廠商不同開發技術的系統拼裝起來的，所以系統和系統之間的溝通，並不一定會發生在同一個資料庫裏面。而且這麼設計，會把系統個體之間的相依性綁得太緊，導致以後牽一髮動全身。如果我們把每一個功能(購物網站、訂單、出貨、庫存、發票…等)都設計成獨立的系統，有各自獨立的資料庫(儲存體或資料表)，也都可以獨立運行，那在架構設計上，將會更加彈性和靈活(其實這也導致後來逐漸成形的微服務概念)。而這樣的設計，就會導致系統和系統之間，需要透過『訊息或事件』來...

Service Bus中文叫做服務匯流排，在使用 Service Bus 前，請先透過底下方式建立: 建立好 service bus 後，接著我們就可以透過程式碼來操作，昨天的文章中，我們提過可以透過 service bus 中的 queue機制，來做 load leveling 架構。至於如何存取 service bus, 我有參考az-204課程，寫好一個範例程式碼，位於github，你可以透過底下指令來下載: git clone https://github.com/isdaviddong/az204-ServiceBusLab.git 從 github上clone我寫好的範例之後，你可以替換其中的連線字串，並且透過azure portal在service bus中建立名稱為『az204-queue』的 queue，即可執行該範例進行測試: 從上面的展示中你可以看到，我們透過兩個console app，一個作為訊息(message)的發送方，一個作為接收方，成功地透過service bus的queue來傳遞訊息與溝通。 如此一來，你就可以實現先前我們介紹過的 queue-based load leveling等機制。

不是所有東西都要寫程式的。 最近幾年，又開始流行No Code/Low Code Solutions，RPA(Robotic Process Automation, 機器人流程自動化)就是其中之一。 微軟在SaaS和PaaS平台都有相關的服務，M365的SaaS平台中，Power Automate就是RPA解決方案，可以讓power user用拖曳設計的方式，撰寫少量或幾乎不用撰寫程式碼，就可以完成一些自動化流程。 而PaaS平台上，就是Azure Portal中的 Logic App 。 什麼是Logic App 技術人員可以把透過Logic App，用拖拉組合的方式，把一個流程設計出來，定時或在特定事件發生時，觸發後續的一連串動作。例如，當用戶把檔案上傳到 OneDrive，就自動進行圖像的人臉辨識，然後把辨識結果發送mail給特定人，如今這樣的流程，你完全不需要寫一行程式碼即可以完成。 透過這樣的方式，你可以大幅的簡化人工作業流程，乍聽之下，它跟Azure Functions, Power Automate都很像，但還是有些差異，Azure Functions雖然有binding功能，但主要還是透過撰寫function code來進行核心邏輯的處理，而Power Automate比起Logic App則比較偏向於End-User用戶端，Logic Apps中的connector和trigger則比較偏向雲端服務的整合。 具體差異可以參考微軟官方文件『 Logic Apps、Functions、WebJobs 和 Power Automate 之間做選擇 』 建立Logic App服務 當你建立好一個Logic App服務之後，緊接著可以建立工作流程，底下影片展是如何在 Azure Portal 上 建立一個Logic App服務: 建立與使用Logic App自動化流程 建立好了服務之後，我們接著就可以建立一個流程，建立的過程中，我們需要選定 trigger 也就是觸發條件。 請看底下的例子，我們在用戶上傳檔案到 onedrive 的時候，觸發流程，然後透過 outlook connector 來進行後續的自動化動作，將上傳的檔案名稱與路徑寫入mail中發送給特定用戶: 從上面的設計展示影片中你可以看到，onedrive conn...

無論是實踐單一登入(SSO)所需要的身分驗證，或是採用OAuth機制，讓用戶授權第三方應用程式來存取受管理的資源，都會從『建立一個應用程式』開始。 Google, 微軟, Twitter, LINE…都有自己的OAuth機制。Google 位於API Console, 微軟位於Azure AD，而LINE 則是使用LINE Login…這也是你常常會看到現在許多網站都有支援各種SSO身分驗證機制的原因: 在Azure AD註冊應用程式 底下我們以微軟的身分驗證機制，拿Web類型的第三方應用程式來做例子，這段影片，示範了如何在Azure AD上建立一個應用程式: 從上面的展示，你會看到我們在Azure Portal上建立好一個 App, 並設定Redirect URL，並取得App ID。建立時，身分驗證類型有四種: 分別是: A. 企業用，只支援該AAD所屬企業 B. 企業用，支援所有具有AAD的企業 C. 企業(to B)+個人(to C)，上述B加上個人帳號( 例如hotmail.com , outlook.com , msn.com …等) D. 僅限個人帳號登入，例如 hotmail.com , outlook.com , msn.com …等 接著，我們要建立並取得待會Web應用程式需要進行身分驗證時，所需要的 App Secret: 另外別忘了，再次檢查設定好的redirect URL，測試階段我們先用 localhost: 完成之後，我們就可以來測試一下，如何使用OAuth的身分驗證機制來取得access token。 OAuth Authorization Code Flow 依照OAuth的Authorization code flow流程，我們的作業流程分成兩個階段， A> 第一個階段我們做身分驗證，並取得代碼(code)， B> 第二階段再拿code去跟伺服器端要access token。 第一階段，我們需要提供底下這些資訊(剛才都已經蒐集到): App Clinet ID redirect URL 微軟AAD使用的 endpoint 為: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?respon...