一般使用者需要做身分驗證，呼叫 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 在討論的主要是，使用者該如何參與這個流程，這些細節會留到未來再詳細說明。

參考資料

• 個人資料保護法
• GDPR
• 薪情平臺
• OAuth
• RFC 5849 - The OAuth 1.0 Protocol
• RFC 6749 - The OAuth 2.0 Authorization Framework