💡 本篇會介紹使用OAuth2.0做授權流程，所以需要具備一點OAuth2.0的概念和知識再來看會比較好哦！

上一篇我們已經完成Azure Active Directory的應用程式註冊設定，接著我們要做的就是驗證是否可以成功使用授權API，這裡我們會用到【POSTMAN】這套工具，另外我們需要到微軟的OAuth2.0授權流程官網【點我前往】Import一下微軟提供的POSTMAN Collections



OAuth2.0的四種標準授權流程和擴充流程

  1. Authorization Code Flow：授權碼流程
  2. Implicit Flow：隱含流程
  3. ROPC（Resource Owner Password Credentials） ：密碼認證
  4. Client Credentials Flow：用戶端認證流程
  5. Device Authorization Flow：裝置授權流程（擴充流程 - 【RFC 8628】）

匯入微軟提供的POSTMAN Collections後可以看到基本OAuth2.0的四種流程微軟都幫你做好範例了，另外也提供了擴充授權流程 - 裝置授權【Device Authorization Flow】給我們測試哦！（真是佛心來的XD）




使用Authorization Code Flow

這個一定是最常見也是大家最常用到的授權流程而市面上的Single Sign On也都是走這個，那麼如果要用Azure AD實作整個OAuth的Authorization Code Flow流程要怎麼做呢？


首先我們在POSTMAN建立一個空白頁簽，接著切換到在Authorization的Tab裡面找到Type並且切換到OAuth2.0

  • Token Name：Token Name隨便取一個名字即可
  • Grant Type：授權方式，我們示範的是Authorization Code Flow因此直接選擇Authorization Code
  • Callback URL：回傳授權碼的轉址位置，用POSTMAN測試所以直接使用POSTMAN提供的轉址位置即可
    💡 這個參數名稱每間都不一樣，有人叫做Callback URL也有叫Callback URI、或是Redirect URL/Redirect URI都有XD，不管名稱為何這個欄位都是提供Authorization Code流程回傳授權碼（Code）的轉址位置
  • Auth URL：授權伺服器驗證URL
  • Access Token URL：驗證成功後取得Token的URL
  • Client ID：用戶識別碼，直接帶入Azure AD的應用程式識別碼
  • Client Secret：用戶識別密碼，這裡要填入Azure AD你所設定的用戶端密碼
    💡 注意！微軟的OAuth做身份驗證時在WebAPP或是WebAPI才需要帶入Client Secret，如果你的Callback URL在Azure AD上的平台設定是Public Client（行動應用程式與桌面應用程式）的話如：POSTMAN或是瀏覽器則不需要帶入【詳細可以點我參考】，否則微軟的OAuth驗證會在你要取得Token時會回傳"AADSTS90023: Public clients can't send a client secret."的錯誤訊息哦！
  • Scope：請求的權限
  • State：狀態欄位（可選的），這個可以拿來驗證用和防止CSRF攻擊用途，這裡範例我就帶入簡單的數字即可
    💡 關於State我有找到Google Login的OAuth2.0 Document對於State的用途解說【點我前往】
  • Client Authentication：Client發送驗證時Token是放入標頭（header）還是放在Body上，基本都是放在header所以就直接預設Send as Basic Auth header


參數填寫完之後就可以使用下方的按鈕「Get New Access Token」來執行



上面我們可以看到POSTMAN執行了OAuth的Authorization Code Flow的整個過程包括導向登入、對Resource Owner取得授權的詢問、以及轉址等等一連串的流程


另外微軟提供給我們的POSTMAN WorkSpace的OAuth2.0 Authorization Code Flow所需要的API全部都幫你寫好了，如果有需求需要自己實作直接參考這四個API然後照著Authorization Code Flow的流程去實踐即可



使用Client Credentials Flow

Client Credentials Flow是一個我覺得常會用到的Auth Flow之一，但它跟Authorization Code Flow有著不同的應用場景，Authorization Code Flow最重要的就是要有「資源擁有者這個角色介入授權」而Client Credentials Flow則是恰恰相反它適合「沒有資源擁有者的情況」譬如：背景服務等等，而Client Credentials因為少了資源擁有者這個角色因此流程就簡化很多


使用剛剛的空白頁簽，但是我們需要將Grant Type調整為Client Credentials

  • Token Name：Token Name隨便取一個名字即可
  • Grant Type：授權方式，我們直接選擇Client Credentials
  • Access Token URL：取得Token的URL
    💡 如果走的是Client Credentials則要使用「https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token」這個API去取得Token，其中{tenant}參數是Azure AD的租用戶的識別碼
  • Client ID：用戶識別碼，直接帶入Azure AD的應用程式識別碼
  • Client Secret：用戶識別密碼，這裡要填入Azure AD你所設定的用戶端密碼
  • Scope：請求的權限，直接使用「https://graph.microsoft.com/.default」這個權限
    💡 由於Client Credentials沒有所謂的資源擁有者這個角色介入授權，因此Scope權限必須在Azure AD應用程式裡面設定好，然後在請求Scope參數直接使用「https://graph.microsoft.com/.default」
我們可以看到跟Authorization Code Flow比少了兩個參數Callback URL和Auth URL，那是因為Client Credentials不再需要驗證這件事情它本身就帶有Client ID和Client Secret可以直接跟OAuth授權伺服器直接要到Token


參數填寫完之後直接按下按鈕「Get New Access Token」


可以看到POSTMAN執行OAuth的Client Credentials直接拿到了Token比起Authorization Code Flow簡單很多，如果想要參考Client Credentials的運作則可以【點我前往參考】


最後來看微軟提供給我們的POSTMAN WorkSpace的OAuth 2.0 Client Credentials Flow API就一個而已（另外一個是「向目錄管理員要求權限」，這個流程可自由選擇要不要實作），如果要實作也可以拿來參考




使用ROPC（Resource Owner Password Credentials）

ROPC這個流程它是直接拿到帳號密碼加上Client ID和Client Secrect直接要Token，當然這個是極度不安全的流程，比較適合資源擁有者與用戶端極高的信任才行



在Azure提供的ROPC上有一堆限制譬如：API權限不只要添加還需要管理員同意、不能使用個人帳戶、受邀進來的租用戶也無法使用、只能用Azure AD內的租用戶等等，所以在實作上需要注意的細節有很多


ROPC也只有一個API，它請求網址比較特別一點「{tenant}」必須填入你的「租用戶識別碼」

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

  • Client ID：用戶識別碼，直接帶入Azure AD的應用程式識別碼
  • Scope：請求的權限
  • Client Secret：用戶識別密碼，這裡要填入Azure AD你所設定的用戶端密碼
  • Username：使用者的帳號
    💡 在Azure AD只能使用租用戶端點的帳號，無法使用邀請或是個人帳號
  • Password：使用者的密碼
  • Grant Type：授權方式（走ROPC固定就是password）


我們送出API後會發現錯誤訊息（圖1）問題大概是指「權限不足」，可是（圖2）明明就有加權限啊！後來研究了一下API權限設定的地方還必須要經過管理員的同意，也就是說就算是不需要經過管理員同意的API權限（圖2有一個欄位「需要管理員同意」）最終也都要經過管理員授權同意（圖3）才可以使用（有夠麻煩的XDD）
圖1


圖2

圖3


經過一番波折後重新調整一下Azure AD應用程式的權限並且讓系統管理員同意後就可以正常拿到Token了


從上面來看ROPC除了不安全之外設定上的限制也非常的多，因此除非萬不得已不然就不要使用拉XDD



使用Device Authorization Flow

💡 在Azure AD上使用Device Auth Flow必須有一個先決條件那就是你需要有一個學校或是企業組織的帳號，如果是個人帳號的話Device Auth Flow是不會讓你登入做驗證的哦！

💡 Device Authorization Flow大多用在沒有瀏覽器或是輸入裝置受限的環境，如：智慧型電視、物聯網裝置或印表機，詳細可以看看微軟這篇的介紹【點我前往】，我看完後的OS：該不會XBOX就是走這個吧！（實際上我完全沒有玩過或碰過XBOX，所以只是猜測而已哈哈）


最後我們來看設備授權流程，基本上就是先驗證設備後取得一個設備碼，接著只要設備驗證完成後用設備碼加上Client ID就可以取得Token，聽起來是不是挺簡單的XD，而微軟提供的POSTMAN Workflow一樣有提供Device Auth Flow！



首先需要一點前置設定，先來到Azure AD的應用程式把「平台設定」→「行動應用程式與桌面應用程式」→「把https://login.microsoftonline.com/common/oauth2/nativeclient打勾」，然後下面的「允許共用用戶端流程」也給打開

💡 如果沒有打開這些設定會無法要到Token


上面設定完成後我們使用POSTMAN使用Device Authorization的API，而Device Auth Flow的驗證網址跟ROPC一樣都是需要帶入租用戶識別碼「{tenant}」
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode
  • Client_ID：用戶識別碼，直接帶入Azure AD的應用程式識別碼
  • Scope：請求的權限


打完API也請求成功後會在Response上看到回傳訊息，其中幾個是比較重要的參數為以下：
  • User_code：這個是驗證代碼，顯示給User看的一個代碼
  • Device_code：設備代碼，需要讓你的設備/程式記住這個代碼
  • Verification_uri：驗證網址，我們要產生這個網址的QRCode或是想辦法讓USER導入這個網址去輸入設備的驗證代碼做驗證
  • Expires_in：驗證碼的過期時間


這裡我們就直接用Chrome進去設備驗證的網址【點我前往】，輸入User_code之後會要求你登入公用帳號或學校帳號，登入成功後就可以關掉網頁





接著我們使用Device Access Token的API，跟Device Authorization和ROPC一樣都是需要帶入租用戶識別碼「{tenant}」
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

  • Grant_type：固定值→「urn:ietf:params:oauth:grant-type:device_code」
  • Device_code：剛剛驗證完成的設備代碼
  • Client_ID：用戶識別碼，直接帶入Azure AD的應用程式識別碼


最後只需要送出API，完成！後續Token失效之後就直接使用你的Device Code搭配Client ID就可以一直取得Token囉！



從POSTMAN來看就只是兩個API打來打去看似簡單不過實際上的情況則是你的裝置設備會不斷的用輪詢（圖1 - loop區塊）去檢查（圖1 - loop區塊內做的事情）你到底做完驗證（圖2 - 檢查回傳的JSON）沒有哦！




圖1

圖2


剩下Implicit Flow因為需求沒有用到因此也就沒有去實作他了，不過大致上微軟的官網都有告訴你該如何實作，有興趣的話可以去官網看看囉！


參考資料：