.NET Walker

這幾天在整理帳號。 我們先前介紹過 Microsoft Graph API ，你應該知道MS Account支援OAuth進行授權和身分驗證。也就是說，你透過你的MS Account登入某些網站或系統時，該應用程式可能會跟你索取你帳號的一些使用權限，那個畫面往往長得像是底下這樣(其實不只MS Account，你的google account更常被這樣使用)： 最基本的，就是跟你索取你帳號的個人資料(像是姓名、email…etc.)，當你用某個MS帳號登入第三方系統時，這是最常見的狀況。 但除此之外，你可能在按下『是』的時候，還同時間授予了該應用一些權限，諸如存取你的通訊錄、行事曆、或是你的onedrive檔案資料夾…等(這些權限的索取都會顯示在上面的清單中，但很多人沒有特別留意)。 一般來說，這些應用程式企圖取得這些授權並非惡意，只是為了做一些系統整合，像是把某一個預約添加到你的行事曆中、或是把手機上的照片存到你的Onedrive內這樣。 但，當某些App我們不常使用(或是該App被認為有安全性疑慮)時，你最好重新檢視一下你到底開了哪些權限給甚麼App? 底下這個位置，可以看到你到底授權了哪些應用程式存取你的MS Account。 https://account.live.com/consent/Manage 出現的畫面類似底下這樣： 你可以看到那些應用程式(或網站)可以存取你的帳號，點選編輯，將出現該應用程式可以存取你哪些資訊的細節： 畫面中列出最近一次的使用時間其實蠻貼心的，這有助於讓你更放心的決定是否要把授予該應用程式的權限刪除，一旦刪除了，該應用程式就無法拿著token去取得你的資料了。 當然，如果你要重新授予該應用程式權限，大部分的狀況下只需要重新用你的MS Account帳號登入該應用程式即可，如果你不很確定，可以看看最近一次的使用日期，如果很久沒用了，應該可以大方的將授予該應用的存取權限刪除。 趁著假日，趕快看看你的帳號到底給了哪些人(app/網站)哪些存取權限吧。

我們 前面 曾經和大家聊過，如果要幾句話說清楚Microsoft Graph API是啥，其實並不很容易，但透過 先前的介紹 你大概可以知道，Microsoft Graph API身為MS Office 365所有資源存取的API連線入口，負擔著讓開發人員得以輕鬆存取雲端資料(資源)的重要角色，只要你想存取Office 365、OneDrive、OneNote…等各種資源，基本上你就必須與Graph API打交道: 不管用戶採用的是個人帳號(Microsoft Account)或企業帳號(Orgnization Account)，MS Graph API讓開發人員可以用單一Endpoint允許各種不同帳號的身分驗證，當然也會依照權限吐出不同的資源。 這一篇我們接著來看，如何透過OAuth連結MS Graph API，並且取得token抓取用戶資料。 (如果讀者對OAuth還不甚了解，請先參考 這裡 ) 建立Microsoft應用程式 首先，若您是開發人員，要使用MS Graph API(或者是要與O365/Onedrive等系統做SSO)，你必須先在微軟的站台上建立一個Application，建立的位置在: https://apps.dev.microsoft.com/ ，進入之後會看到底下畫面: 請用您的Microsoft Account登入，您就可以建立一個自己的應用程式: 點選後會出現底下畫面，依照步驟，輸入名稱，按下建立鈕: 建立完應用程式之後，請接著點選『產生新密碼』: 記得保留上面彈出視窗中顯示的密碼，待會我們會使用到(它只會顯示一次，請務必自行保留)。 接著，請在平台這邊選擇新增平台，然後選Web，這是因為我們範例中是透過Web App整合方式來進行Demo，如果你的情境是要在行動裝置上存取Office365(or Onedrive/onenote…etc.)中的資源，當然就選擇行動應用程式: 接著該頁面會要求你輸入重新導向URI，這部分如果不理解其意義以及為何需要，請參考我們以前分享過的 OAuth介紹文 ，底下的URL就是你取得Auth Code的導回網址，由於我們只是要在Local用IIS Express測試，因此我們網址輸入Localhost: 至於port 13555怎麼來的，它是我們在VS2015中建立了一個Web ...

最近的 Line Notify 、 Line Login ，以及前一陣子的 Microsoft Graph API ，全都使用到了OAuth作為用戶身分驗證以及資源存取的基礎。但很多讀者會卡在OAuth的運作流程上，根本的原因是不理解OAuth到底是幹嘛的?其存在的目的為何?以及如何應用? 因此，我想花一個篇幅，盡可能短的介紹一下OAuth與SSO，但，與坊間文章不同的是，我希望從應用情境的角度(而非技術)切入談這件事情，冀望能夠讓開發人員對OAuth有個最基本的認識。 OAuth的背景 我們回頭看 Line Login 與 Line Notify 中的例子，OAuth在這邊最簡單的應用情境，就是身分驗證。典型的情境中有幾個角色，分別是: 網站或App的開發單位 : 也就是各位開發人員 OAuth服務的提供者(Provider) : 也就是Line(或Google、Microsoft…etc.) 終端用戶(End-User) : 網站使用者、Line使用者、消費者、客戶…etc. 上面這三者的關係是什麼？ 當我們建立一個網站（例如Pc Home購物）、或App(例如一個手機遊戲)，都非常有可能需要建立一組會員機制，這些機制包含: 登入（包含身分驗證，帳號、密碼保存…等） 個資管理（用戶名稱、地址、電話、暱稱、手機…等) 以往，幾乎都是每一個網站自己做一套，但這樣有很多麻煩事，首先用戶要記得很多組帳號密碼，而每一個網站都自己搞一套會員機制，網站開發人員自己也很辛苦，加上最近這幾年大家都很重視個資，網站儲存（保管）了很多帳號密碼與個人資料，總是會有被駭的風險。因此，這十年來，很多大廠開始提供登入（與身分驗證）機制服務。 也就是說，小網站你不用自己做登入和會員管理了，你連過來我這邊，我是大網站，我已經有幾百萬上億的用戶，(例如全台灣都用Line)，而且早就做了超級安全的會員管理機制，你這小網站何必自己做會員管理呢？你跟我連結不就得了，我大網站來幫你管理個資，提供你登入的服務，你把會員資料通通存我這裡，用戶也不需要記得很多組帳密，只需要記得我大網站的帳密，一樣可以登入你小網站(或稱為第三方應用）來使用你提供的服務，這樣皆大歡喜。 因此，大家就這麼做了。 但提供這樣服務的大廠越來越多，Google、Microsoft、Yahoo…都提供了這樣的...

Microsoft Graph API的前身叫做 Office 365 unified API。這什麼東西呢? 這是一套可以access Office 365中各種服務的資料的API，簡單一點說，就是透過這組API你可以存取O365中用戶的資訊。 你看到unified這個字眼，可能會猜測，那它出現之前，可能有一個比較不unifie的API囉? 是的，你沒猜錯。 這一段路是有一個演進的過程的，我們先來介紹一下，我嘗試說個簡易版的故事。 首先，會接觸到這個API，是一年多以前的事情了，那時Office 365開始在台灣推廣，我們需要撰寫一些程式碼來存取O365上的資訊(像是用戶身分、行事曆、檔案…等)。 那，微軟這麼大的軟體公司，應該會有提供一套什麼API來存取這些資訊，用起來應該很簡單，對吧? 如果你這麼想，那就…稍微天真了。 提供API是有的，但你會好幸運的發現，不是提供一套API，是好幾套API。為何呢? 因為本質上Office 365根本就不是『一套』軟體。 什麼意思? Office 365，其實一堆軟體服務(SaaS)的集合，請記得這一點，它不是一套軟體，它是一群軟體所形成的一個平台。例如Office 365中的檔案，其實是Onedrive特殊版，筆記本是OneNote，email、行事曆是Outlook，通訊錄要看你想要抓哪種，有AD的，有email用的…這，還只是個開始。 如果你觀察Office 365，你會發現他一直在長大，最近還推出了 Planner 、Power BI、Flow …等等等、等等等。聽說以後還要推出類似Slack的 Skype Team ，總之Office 365跟你想的可能不一樣，它並非是一套軟體，他是很多套軟體服務。 而這很多套軟體服務的網址(網站)根本不同，只是每一個網站之間用oAuth做單一登入(SSO)的身分驗證而已，讓用戶用起來『像是(但根本不是)』在同一個網站裡面，但其實你是在多個網站裡切來切去。 那，這就讓developer很頭痛了，因為你以為的『抓取Office 365的資料』，其實不是在跟一組API打交道，是跟一群API打交道，每一種API都有自己的呼叫方式，都要做一次身分驗證，每一個驗證都要先取得授權，這…也太痛苦了吧。 寫到這邊，你就該知道unified 的必要了，這也是Office 365...