從 0 開始的開放生態圈 — OAuth 篇

Hi Shari Wu

Published in

jkopay@frontend

6 min readJun 17, 2022

相信大家一定串過各種的第三方 OAuth，而我們也打算有一套 OAuth 讓第三方在我們生態圈建立服務時，可以直接使用我們的登入機制，這有什麼好處呢？

登入成功後，可以向街口拿取使用者資訊
提供綁定第三方使用者帳戶與街口帳戶的功能（當街口登入時，也代表該平台也被登入）

接下來與各位分享有關 OAuth 被建制的過程

OAuth 還沒有納入開發者平台之前

首先建立一張 ISV 表紀錄有哪些三方，其中也包括該三方權限配置等等重要資訊。其中最重要的是 clientID、scope (想要拿取的授權範圍)。

ClientID 是什麼呢？

在第三方要登入街口時，我們提供一個 function 叫做 getAuthCode，當三方帶入 clientID 及 scope 就能喚起授權頁面。

這部分完全沒有問題，但如果今天他要納入開發者平台，我們該怎麼去思考設計方式？

OAuth 如何加入開發者平台

起初我們定義第三方一定會使用 OAuth 服務，所以一開始在開發者平台建立應用程式時，就直接幫三方申請好 OAuth 服務了。

這讓後面的服務嵌入變得綁手綁腳的，於是乎我們將兩者位置調換一下：

後端與開發者平台的主控權反轉

太好了，由上圖很明顯看到，權限由後端主控轉移到了開發者平台本身，如此一來，每次新增一個服務時，不會被綁死，所有服務都能由開發者平台開始決定要不要啟用這項服務。

授權頁怎麼來的？

不就是一個單純的靜態頁面嗎？起初我也這樣想，不過事情發展超乎我的想像。

觀察下方版本一跟二差異：

在版本一時，PM 說：

我要一個描述 scope 區域加上條款說明區塊，而且有固定挖空內容位置

在版本二時，PM 又說：

除了版本一之外，我還想要更多能力描述區塊，甚至我還想要 “更彈性挖空內容位置” 。

大家可能想什麼是更彈性挖空？就是全部挖空就好拉！ＸＤＤＤ

這樣有挖跟沒挖一樣，如果今天不同人填寫就有不同的樣板，那還要樣板幹什麼呢？

OK，現在不是抱怨的時候，我們來想想有什麼辦法解決。

區塊分析

什麼是一定不變？區塊內的大方向不變

我們將上述區塊拿出來抽象化，就跟寫 Component 依樣開心～

此時用這個概念去跟 PM 博弈

確認每個區塊內部都是一樣的大架構，要怎麼變隨便你們，例如：

注意事項 可能不會有條款
綠色勾勾項目 可能不會有要 寫死的項目

每個區塊雖然都一樣，但是名字不一樣，意義也不一樣，例如：

第一個區塊 開放能力區塊：例如街口帳號與平台帳號綁定
第二個區塊 個人區塊：專門顯示第三方要授權的 scope
第三個區塊 註冊條件區塊：顯示特殊使用者等級註冊條件

在相同區塊架構下，我們可以有足夠的靈活度。

讓區塊（單元）變成組件（多個單元）

假設組件 json 長這樣

"blocks": [
    {
      "type": "userTerm",
      "typeValue": "{{typeValue}}",
      "description": "A",
      "items": [
        "xxxx"
      ],
      "cautions": {
        "title": "注意事項",
        "content": [
          "oooooooo"
        ]
      }
    },
    {
      "type": "functional",
      "description": "{{客製化欄位}}",
      "cautions": {
        "title": "街口帳戶功能注意事項",
        "term": "{{客製化欄位}}",
        "content": [
          "{{客製化欄位}}"
        ]
      }
    },
    {
      "type": "information",
      "description": "",
      "cautions": {
        "title": "",
        "term": "",
        "content": [
          "ooo",
        ]
      }
    }
  ]
}

如何決定組件中某區塊要不要出現？

靜態：在樣板組件中一開始就不要放入單元區塊
動態：透過 url query 帶入該 type 的值且不為 false 則要出現
ex: 以上面例子為例，如果 url = https://ooxx?userTerm=cC_B ，因滿足第一個 userTerm block，則要顯示

Template Rendering Pattern

PM 可以開始建立樣板，用組件客製化不同版本的樣板

每個區塊可填寫都一樣，但是內部的樣子可以長得很不一樣！

舉例

問：當有了樣板 (v1) 之後，如果哪天 PM 又要針對特殊的廠商有不同樣板怎麼辦？

答：那就再建立第二個樣板叫做 (v2)

授權頁生命週期

由 Controller 呼叫 “api-v1” (可呼叫不同的版本，他會對應不同樣板)
建立完授權頁 Json Schema 後用 clientID 為這份檔案命名
當前台要顯示授權頁時只要抓對應的 clientID 就可以拿到資料。
若特定第三方（clientID) 要吃不同樣板 (v2)，就打 api-v2，其他第三方不會被影響到。

這樣好處是

樣版與真正的 config file 不互相依賴
彈性變更樣板：當樣版從 v1 -> v2，view 不需要更動

延伸探討

這個概念在前端其實廣泛應用在開發元件上，即是 view 與 logic 分離，如果有時候可以跳脫思考，那這個概念就可以被應用在很多地方。

先說這麼做不一定是最好的解法，同時我們也一直在思考文案系統要怎麼做可以最彈性，當已上線的專案又要一直改文案，對 RD 來說是很浪費時間的事情。

How to make it easy?

讓事情變簡單好上手，之後才不會有煩惱～