關於Forge認證機制，一開始在學習的時候真的是觀念模糊，這天閱讀官方文件，加上之前對於使用者認證的了解，將OAuth常見的幾個名詞與觀念做陳述

OAuth

OAuth是token-based的驗證機制，這樣的認證機制是利用tokens 確保每筆發送到server的request 都是被認證過的。在前一篇文章我們創建forge app後得到的client ID與secret就如同使用者登入應用程式的帳號與密碼，forge app透過這組資訊向遠端發送request獲得access token後，往後我們的應用程式向forge platform發送request時就會在header帶上這筆token作為訪問許可。

驗證的方法與流程主要分成two-legged authentication與three-legged authentication:

two-legged authentication

簡單來說，這種驗證機制互相溝通的成員只有兩位（所以稱為兩條腿）：我們的應用程式與forge 平台。當我們的應用程式不需要讀取第三方的資源，僅僅只是取用 forge platform上的api時，這樣的溝通方式流程如下：

• 應用程式發送(POST)client ID與secret獲取調用api 的權限
• 經由遠端forge platform認證通過後，回傳 access token給我們的app
• 應用程式調用forge platform api時，發出的request header攜帶著access token
• token失效時，重新執行上述的步驟獲得授權

three-legged authentication

three-legged authentication比起two-legged則是多了使用者在第三方的資源訪問授權，其過程包含

• 應用程式發送訪問請求獲取user 資源
• user 登入核准訪問
• forge platform回傳access token給應用程式

當我們需要獲取的內容是儲存於某個使用者在第三方空間儲存的資料，像是BIM 360或其他應用程式等，則需要透過我們的app發送request，如果這個第三方是BIM 360，則會自動導入Autodesk登入流程，讓使用者確認是否讓我們的應用程式獲取自己的資料，同意的話則授權通過，將這樣的資訊回傳給forge platform，forge platform再發送access token允許我們的應用程式獲取user的第三方資源。

callback url

上一篇文章提到的callback url在two legged authentication不會使用到，原因在於這個url指的是在第三方授權訪問後，browser自動指向的一個位置，用於將authorization code回傳給我們的應用程式，之後才是由我們的應用程式發送authorization code以及app的client ID,secret給forge platform獲取access token，故事大概是這樣。

事實上，access token也有其能夠訪問資訊的範圍限制，這個部分之後到了實作時再一一道來，下一篇文章即將進入實作階段，會需要先在電腦安裝好node.js，準備好你想要上傳的模型檔(.rvt)以及你的forge app Client ID與secret，我們明天見(眨單眼

Ref

• https://forge.autodesk.com/en/docs/oauth/v2/developers_guide/basics/
• https://www.okta.com/identity-101/what-is-token-based-authentication/