API 身分驗證
一般使用者需要做身分驗證，呼叫 API 一樣也需要做身分驗證。只是因為情境與角色不同，所以驗證方法會稍有不同。
大部分的 API 設計目的都是讓其他服務呼叫（也有讓使用者呼叫的 API，只是比較少），而在開放 API 讓其他服務呼叫之前，得先思考幾件事：
若 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 的帳號密碼給美圖軟體，這樣就可以讀取使用者的照片了。
只是這樣做會有下面的缺點：
- 美圖軟體必須保存使用者的密碼才能繼續服務
- 美圖軟體有了使用者的帳密，代表同時擁有使用者在 Facebook 的所有權力，完全無法限制範圍和期限
- 使用者只有改密碼才能回收權力，但使用者所有「有提供帳密的第三方應用程式」會同時無法使用
- 只要有任一個第三方應用程式被駭客入侵了，就會導致使用者密碼外泄（參考第一點），甚至 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 在討論的主要是，使用者該如何參與這個流程，這些細節會留到未來再詳細說明。