iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 15
3
Security

我是誰?我在哪?系列 第 15

API 身分驗證

一般使用者需要做身分驗證,呼叫 API 一樣也需要做身分驗證。只是因為情境與角色不同,所以驗證方法會稍有不同。

大部分的 API 設計目的都是讓其他服務呼叫(也有讓使用者呼叫的 API,只是比較少),而在開放 API 讓其他服務呼叫之前,得先思考幾件事:

  1. 此 API 的內容有沒有個人資料?
  2. 使用者條款是否有說明個人資料的使用方法?
  3. 國家法律是否有限制個人資料的使用方法?(如個人資料保護法GDPR 等)

若 API 有包含個人資料且有受到法律限制,那就得注意法律的限制,像個資法第五條就有提到:

個人資料之蒐集、處理或利用,應尊重當事人之權益,依誠實及信用方法為之,不得逾越特定目的之必要範圍,並應與蒐集之目的具有正當合理之關聯。

這代表就算使用者同意使用網站所制定的使用者條款,但其他服務想使用這些資料的時候,依然還是得尊重使用者的意願來決定是否提供資料,這正是授權的基本概念。

相反地,若 API 並沒有法律或條款所稱的「個人資料」,如政府提供的薪情平臺即是沒有個人資料的公開資訊,這類的 API 則不需考慮授權的問題,而是單純考慮服務之間的資訊交換即可。

信任服務

這是最常見也最原始的方法。經由雙方約定並限制某些條件,讓雙方可依此條件做為信任的標準,也就是白名單機制。常見的幾個例子如下:

  • 鎖 IP,限制特定 IP 才能呼叫 API
  • VPN,限制只有在 VPN 環境下才能呼叫
  • Token,限制只有該 token 能呼叫 API

其中鎖 IP 是最為麻煩的方法,因為 IP 為網路層(Network Layer)即可得知該內容,但若不同的路徑要有不同的限制時,那就只能在應用層(Application Layer)處理,這可能會令開發者不清楚在哪處理比較恰當。另一個問題則是,只要一鎖 IP,代表未來系統架構的彈性就可能會降低。

而 token 則是相較彈性,且有相關的規範和安全注意事項可以參考。

另外一開始有提到,使用者直接呼叫 API 也是類似這個場景(把使用者當作一個服務看待),因此如 GitHub 會提供 Personal Token 即是解決使用者呼叫 API 時,要做身分驗證的需求。

簡介 OAuth 2.0

現今的社群服務非常多,如 Facebook。使用者可以利用這個服務上傳個人照片,並分享給好友。

今天有一個美圖軟體,功能是把使用者上傳到 Facebook 的照片做修圖。使用者要用這個服務的話,必須讓美圖軟體能存取使用者儲存在 Facebook 上的照片。美圖軟體並不是使用者本人,所以無法存取使用者放在 Facebook 上的照片。因此,要讓美圖軟體存取,最直覺最簡單的方法:使用者將 Facebook 的帳號密碼給美圖軟體,這樣就可以讀取使用者的照片了。

只是這樣做會有下面的缺點:

  1. 美圖軟體必須保存使用者的密碼才能繼續服務
  2. 美圖軟體有了使用者的帳密,代表同時擁有使用者在 Facebook 的所有權力,完全無法限制範圍和期限
  3. 使用者只有改密碼才能回收權力,但使用者所有「有提供帳密的第三方應用程式」會同時無法使用
  4. 只要有任一個第三方應用程式被駭客入侵了,就會導致使用者密碼外泄(參考第一點),甚至 Facebook 上的所有資料與所有第三方應用程式都會外泄

OAuth 正是為了要解決上面這些問題的框架。

OAuth 也有歷史可以回顧:首先在 2007 年發布了 OAuth 1.0 的草案,而在 2008 年 IETF 決定納入並做進一步的規格化。只是在 2009 年,OAuth 自己發現了 OAuth 1.0 的安全漏洞,隨後發布了 1.0a 版來修正。2010 年,IETF 發布了 RFC 5849 ,但是只做為 INFORMATIONAL 而不是標準,也許 IETF 認為 OAuth 1.0 跟當時的 HTTP/1.0 一樣處於一個不穩定的狀況,因此將它標記為 INFORMATIONAL

到了 2012 年,IETF 發布了 RFC 6749,它正是各大網站所在使用的 OAuth 2.0 Authorization Framework

與單純服務間的串接有點不同,OAuth 在討論的主要是,使用者該如何參與這個流程,這些細節會留到未來再詳細說明。

參考資料


上一篇
帳號密碼驗證
下一篇
第三方身分驗證
系列文
我是誰?我在哪?30

尚未有邦友留言

立即登入留言