回転矢印に囲まれた鍵と、3つの接続先スロットを描いたトークンローテーションの概念イラスト

記事

GitHubのOAuthアプリが刷新——8時間で切れるトークンと最大10個のリダイレクトURIに対応、既存アプリには要確認の変更も

GitHubがOAuthアプリ向けに、有効期限8時間のアクセストークンとリフレッシュトークン、最大10個のリダイレクトURI、ワイルドカードマッチングを導入しました。リダイレクトURIが1つだけの既存アプリはワイルドカードが有効になっており、見直しが推奨されています。

GitHubは2026年8月14日、OAuthアプリとGitHub Appsのプラットフォームに、より安全なアプリ開発のための複数の更新を加えたと発表しました。柱は3つで、OAuthアプリの短命トークン（リフレッシュトークン）対応、最大10個までのリダイレクトURI登録、そしてリダイレクトURIのワイルドカードマッチングです。GitHub連携アプリを運用している開発者には、既存アプリの設定見直しを促す変更も含まれる、実務直結のアップデートです。

8時間で失効するトークンとリフレッシュトークン

これまでGitHubのOAuthアプリのアクセストークンは長期間有効なままで、漏えい時のリスクが課題でした。今回、OAuthアプリはユーザー認証フローで短命トークンをリクエストできるようになりました。オプトインすると、8時間で失効するアクセストークンと、6か月有効なリフレッシュトークンのペアが発行され、アクセストークンが切れたらリフレッシュトークンで新しいペアを取得する方式になります。

導入方法は2つあります。認証リクエストにoffline_accessスコープを含めて短命トークンのパターンを発動させる方法が基本で、テストと段階的な展開に向きます。もうひとつは、アプリの登録設定で常に短命トークンを使うようにする方法で、古いクライアントに更新を強制できます。なお、新規に作成するアプリでは短命トークンがデフォルトで有効です。認証SDKがリフレッシュトークンのフローに未対応の場合は、SDK更新までの間これを無効化できます。

OAuthアプリ設定に追加されたリダイレクトURI管理画面

画像引用元: GitHub Changelog

リダイレクトURIは最大10個まで登録可能に

もうひとつの改善が、リダイレクトURI（GitHubではコールバックURIと呼ばれます）の複数登録です。OAuthアプリは最大10個のリダイレクトURIを登録できるようになり、開発・ステージング・本番といった複数環境や、複数ドメイン、異なるデプロイ構成を、アプリを別々に作らずにひとつで支えられるようになりました。

アプリの設定画面には「Add redirect URI」ボタンが追加されており、マッチング対象のURLを追加していく方式です。環境ごとにOAuthアプリを量産してクライアントIDを管理する、という定番の面倒がなくなります。

ワイルドカードマッチングは「便利だが要注意」

3つめが、リダイレクトURIごとに有効化できるワイルドカードマッチングです。OAuthアプリとGitHub Appsの両方で使え、テナントごとのサブドメインを持つアプリなどで、テナントごとにURIを登録しなくても、サブドメインや追加パスへのリダイレクトを許可できます。

ただしGitHubは、リダイレクト先のサイトがルートを厳密に管理していない場合、たとえばユーザーコンテンツをホストしている場合には、ワイルドカードマッチングが悪用され得ると警告しています。認可コードが意図しないURLへ送られる恐れがあるためで、有効化する前にアプリのアーキテクチャを確認するよう求めています。

既存アプリは「ワイルドカードが有効になっている」ので確認を

今回の発表で最も見落とせないのがこの点です。リダイレクトURIを1つだけ登録しているアプリでは、ワイルドカードマッチングが有効になっています。これはGitHubの従来からの挙動が、今回可視化されて制御可能になったものです。GitHubは、この挙動を必要としないなら無効化するよう、すべてのOAuthアプリと、単一のリダイレクトURIを登録しているGitHub Appsの見直しを呼びかけています。

つまり、今回の更新は新機能の追加であると同時に、これまで暗黙だったゆるいマッチング挙動を明示化するセキュリティ改善でもあります。一連の更新はGitHub Enterprise Server 3.23にも含まれる予定です。

連携アプリ運用者がやるべきこと

GitHub連携アプリを持っているなら、やることは明確です。まず設定画面でワイルドカードマッチングの状態を確認し、不要なら無効化する。次に、環境ごとに分けていたOAuthアプリを複数リダイレクトURIで統合できないか検討する。そして、offline_accessスコープでの短命トークン対応をテスト環境から進める、の3点です。

長生きするトークンは漏えい時の被害を広げる最大の要因のひとつです。GitHubがプラットフォーム側で短命トークンを標準にし始めた今、対応は早いほど安全です。