什麼是 GitHub 應用程式？
在本堂課中，我們將說明什麼是 GitHub 應用程式、其運作方式，以及如何用來改善工作流程。 無論您是採用其他人建置的解決方案，還是自行開發解決方案以符合您的確切需求，都一定還會有改善程序的空間。
透過 GitHub API 來延伸平台
GitHub 提供強大的 API，讓開發人員能在平台上執行幾乎所有的作業。 這是透過 REST 端點公開，因此可以輕鬆與任何平台或程式設計語言整合。 然而，API 存取並無法獨立運作。 想要與其他人共用功能的開發人員，仍然需要將其封裝為應用程式並發佈，才可供其他人使用。
選擇將 OAuth 應用程式或 GitHub 應用程式整合到您的工作流程時，需要考慮幾個因素。 在本節中，我們將介紹 GitHub 應用程式和 OAuth 應用程式兩者的使用方式、權限差異與事件訂閱。
自訂 GitHub 工作流程時，您可以使用數種功能，例如撰寫自訂指令碼、建立和授權您自己的 OAuth 應用程式，或從 GitHub Marketplace 安裝 GitHub 應用程式。 一般而言，您可以針對這些一次性工作使用指令碼。 對於需要更頻繁執行的動作，您可以使用 OAuth 和 GitHub 應用程式的自動化功能，協助您和您的小組節省時間，並維持工作流程的最佳安全性等級。 在決定要選擇使用 GitHub 應用程式或 OAuth 應用程式時，有許多差異可能影響您的決定。 事先了解這些差異可以減少一些麻煩和重新作業，並協助您在工作流程中找到最適合特定使用案例的應用程式。
在本節結束時，您將充分了解 GitHub 應用程式和 OAuth 應用程式的差異，以及如何依據狀況選擇最適合的應用程式。
授與存取權和權限
允許應用程式存取 GitHub 存放庫的其中一個最重要的考量，就是運作所需的權限。 某些應用程式很容易信任，但另一些應用程式可能會令人抱持疑慮。 請務必確保您對於授與某個應用程式的權限感到放心。
注意
每個應用程式都會使用唯一的 API 金鑰，來針對您存放庫中的資料提出要求。 當您授權存取時，實際授權的是金鑰。 您隨時都可以從存放庫設定撤銷應用程式金鑰的存取。
OAuth 應用程式
OAuth 應用程式可用來代表使用者身分存取 GitHub 資料。 由於是代表使用者執行操作，因此請務必注意，它會占用 GitHub 授權基座。 若您有系統管理存取權，可以在個人帳戶或以組織層級建立並註冊 OAuth 應用程式。 與 GitHub 整合的 OAuth 應用程式會揭露需要何種類型的組織或存放庫存取權限。 使用者授權 OAuth 應用程式，讓應用程式能做為已獲得授權的使用者執行操作，例如讀取或修改資料。 這個方法基本上是以使用者身分讀取、寫入或編輯 GitHub 資料的自動化方式。 此外，請務必注意本授權僅限於使用者可存取的資源，不過 OAuth 應用程式也能存取所有使用者可用的資源。
注意
存取層級受限於權杖適用的範圍 (使用者、組織、存放庫)。
對於有 OAuth 應用程式存取限制的組織，管理員可以核准使用應用程式。 透過事件訂閱後，OAuth 應用程式將於活動發生時做出回應。
GitHub 應用程式
反之，GitHub 應用程式是安裝在您的個人帳戶、您的組織或您具有管理員權限的特定存放庫。 GitHub 應用程式是以服務的形式安裝並與 GitHub 互動，而不是像使用 OAuth 應用程式一樣以個別使用者的形式進行互動。 有別於 OAuth 應用程式，GitHub 應用程式的其中一項好處是不會占用 GitHub 授權基座。
GitHub 應用程式會透過用於簽署 JWT 權杖 (JSON Web 權杖) 的私密金鑰，來代表應用程式本身存取資料。 由於它們安裝於特定的存放庫，因此使用者可以選擇應用程式可存取的存放庫，以限制應用程式能存取的資料量。 存取權限定義 GitHub 應用程式可透過 API 存取哪些資源。 有別於 OAuth 應用程式，GitHub 應用程式可以對存放庫資料、問題和提取要求自訂存取權限。 這可讓您授與更為精細的權限，限制應用程式只能在允許存取的存放庫中讀取和寫入資訊。 只有組織擁有者可以管理組織中 GitHub 應用程式的設定。
您可以在 GitHub Marketplace 尋找並安裝 GitHub 應用程式。 搜尋 GitHub 應用程式時，請記得部分應用程式具有通過驗證的徽章。 此徽章顯示該應用程式由組織擁有，其網域已通過擁有權驗證、GitHub Support 已確認電子郵件地址，並需要為其組織進行雙因素驗證。
- 管理員可以授與存放庫系統管理、檢查、存放庫內容、部署和問題的權限 (管理員變更需要使用者接受)
- 管理員可以授與應用程式使用者權限，以封鎖其他使用者、電子郵件、追蹤者、GPG 索引鍵、Git SSH 索引鍵、星星標誌、監看 (管理員變更需要使用者接受)
- 事件訂閱：安全性建議、檢查套件、建立、部署、分支、標籤、成員、存回、認可留言、刪除、部署狀態、里程碑、成員資格、組織 (管理員在 GH 應用程式 UI 中設定，而且可以變更)
GitHub 應用程式與 OAuth 應用程式二選一
雖然 GitHub 應用程式在某些情況下是整合至工作流程的理想方式，但大型組織要從使用 OAuth 應用程式自動化的傳統方式進行轉換可能不太容易。 例如，安全性原則限制可能也會限制管理員使用這些工具的選項。
注意
您身為管理員，應該與開發人員合作找出最合適的自動化功能，既可運用這些應用程式，同時又能遵循安全性原則。
若要判斷哪一個應用程式最適合您的情況，以下是一些需要考慮的重要問題：
- 我想要以使用者身分執行應用程式嗎？
- 需要什麼速率限制？
- 我想要讓應用程式在組織和存放庫中擁有哪些存取權限？
- 此應用程式是否符合我們的安全性原則？
以下是在 GitHub 應用程式和 OAuth 應用程式之間做選擇時需考慮的一些關鍵特性和差異。
| GitHub 應用程式 | OAuth 應用程式 |
|---|---|
| 安裝 GitHub 應用程式會授與應用程式存取使用者或組織帳戶所選的存放庫存取權限。 | 授權 OAuth 應用程式會授與應用程式存取使用者可存取資源的權限，例如他們可以存取的存放庫。 |
| 安裝存取權杖僅限於應用程式建立者所選的指定存放庫可以使用。 | OAuth 存取權杖會受到範圍限制。 |
| 安裝權杖會將應用程式識別為 GitHub 應用程式 Bot。 | 存取權杖會將應用程式識別為授與該應用程式權杖的使用者。 |
| GitHub 應用程式具有目標權限，可以只要求所需內容的存取權限。 | OAuth 應用程式無法使用細微的權限。 |
| GitHub 應用程式不受組織應用程式原則規範。 GitHub 應用程式僅能存取組織擁有者授與權限的存放庫。 | 如果有使用中的組織應用程式原則，則只有組織擁有者可以授權安裝 OAuth 應用程式。 如果已安裝，OAuth 應用程式就能存取組織擁有者在已核准的組織內所擁有權杖上可見的任何內容。 |
| GitHub 應用程式層級 (會影響所有安裝) 和個別安裝層級均可增加速率限制。 | 可針對每個 OAuth 應用程式授與提高速率限制的權限。 每個授與給 OAuth 應用程式的權杖均會增加限制。 |
| GitHub 應用程式可以代表使用者進行驗證，這稱為使用者對伺服器的要求。 授權流程與 OAuth 應用程式授權流程相同。 使用者對伺服器的權杖會過期，可透過重新整理權杖更新。 | OAuth 應用程式使用的 OAuth 流程會代表使用者授權 OAuth 應用程式。 這與 GitHub 應用程式使用者對伺服器授權所用的流程相同。 |
| GitHub 應用程式會要求存放庫內容權限，並使用您的安裝權杖透過 HTTP 型 Git 進行驗證。 | OAuth 應用程式會要求 write:public_key 範圍，並透過 API 建立部署金鑰。 然後，您可以使用該索引鍵來執行 Git 命令。 |
應用程式存取權和權限
允許應用程式存取 GitHub 存放庫的其中一個最重要的考量，就是運作所需的權限。 某些應用程式很容易信任，但另一些應用程式可能會令人抱持疑慮。 請務必確保您對於授與某個應用程式的權限感到放心。
決定要使用 GitHub 應用程式或 OAuth 應用程式，可能取決於您希望應用程式擁有的存取權層級。 一般而言，您應該鼓勵您的小組使用最小範圍的工具來完成工作。 OAuth 應用程式可存取使用者或組織擁有者的所有資源。
- OAuth 應用程式可以擁有 GitHub 資料的讀取或寫入權限
- 您可以授與 GitHub 應用程式的存取權限給一個帳戶，無須授與另一個帳戶權限
應用程式安全性
在應用程式中發現弱點時，應該優先處理該問題並遵循安全性原則告知專案的使用者。 快速傳達安全性問題可帶來不同結果，讓使用者可以撤銷遭盜用的權杖，而不是外洩敏感性資料。 雖然權杖比密碼安全，但仍可能遭到盜用，因此組織務必需做好準備。
除了 README.md 檔案外，建議也將 SECURITY.md 檔案加入您的存放庫中。 SECURITY.md 檔案會醒目提示存放庫中的安全性相關資訊。 檔案應包含安全性連絡人、您的組織原則，並詳細說明發現弱點時要採取的回應。
對事件做出反應
GitHub 應用程式具有被動設計。 它們會等待事件發生，然後再做出反應，而且通常是透過 GitHub API 進行。 等待 GitHub 上發生事件時，有兩種執行的方式：Webhook 與輪詢。
注意
GitHub 應用程式並不限於使用 GitHub 資料。 您也可以等待發生在其他來源的事件，或是執行會更新其他服務的動作。
使用 GitHub Webhook
Webhook 是事件處理的慣用方法。 當 GitHub 上發生位於 Webhook 範圍內的事情時，系統就會立即加以引發。 Webhook 會推播訊息通知您的應用程式可以即時接聽和處理。 您可以在存放庫設定中設定 Webhook，包括事件類型、驗證與傳遞 HTTP 通知的方式。
輪詢的比較 \(英文\)
有時無法使用 Webhook。 您的應用程式可能需要在公司防火牆的後方執行，GitHub 無法直接與其連線。 在該情況下，替代方法是使用 GitHub API 來針對您正在追蹤的資料進行輪詢。
Webhook 轉送
能夠替代對位於防火牆後方的應用程式進行輪詢的方案，便是使用如 smee.io \(英文\) 的 Webhook 轉送服務。 使用此方法時，公用服務將會訂閱存放庫的 Webhook，然後將傳入的資料轉送到在防火牆後方執行的用戶端服務。 該用戶端服務接著會將通知推送到正在執行的應用程式，如同其來自原始來源一樣。