1セキュリティやGitHubAPIに詳しくないので間違っているかもしれない。
5つの認証方法
GitHubAPIを実行するとき、認証方法は5パターンある。
認証方法 | 説明 | 注意 |
---|---|---|
認証なし | 認証せずとも叩けるAPIなら認証なしで実行可能。 | IP単位でのリクエスト上限で60回/1時間。 |
Basic認証 | ユーザ名とパスワードで実行する。 | おそらく全APIを叩ける認証方法だがセキュリティ的に危険。 |
TwoFactor認証 | Basic認証+OTP。アカウントにTwoFactor認証を設定しているなら、Basic認証のときにOTPが必要になる。 | OTPは30秒ごとに変わるし、専用アプリなどで取得する必要があるため、自動化できない。 |
Token認証 | AccessTokenで実行する。この方法が最も安全で簡単。 | APIが要求するScopeを持ったTokenを使う必要がある。 |
ClientId認証 | ClientId, ClientSecretで実行する。Webアプリのときに使うらしい。 | 未知。 |
以下のようなことを検討して使い分けることになる。
リクエスト上限
場合 | 上限 |
---|---|
認証なし | 60回/1時間 |
認証あり | 5000回/1時間 |
認証なしでも使えるAPI、認証ありでしか使えないAPI、分けたほうがいいかもしれない。ただ、APIを全部調べるのは面倒すぎる。リクエスト上限の消費を気にせず、常に認証で実行するほうが楽に実装できそう。
APIごとに認証方法を使い分ける必要がある
APIごとに特定の認証を求められる。
たとえば/users
なら認証せずに使える。/user/repo
はBasic認証かToken認証が必要。
/authorizations
でPOSTしてToken生成するなら、Basic認証しか使えない。
パラメータごとに必要なScopeが変わる
リポジトリ生成APIの場合、private
引数がtrue
かfalse
か(リポジトリがpublicかprivateか)によって必要なScopeが変わるらしい。
Basic認証は万能だがセキュリティ的に危険
Basic認証ならおそらく全API実行できる。しかし、Token認証ではToken生成APIが叩けない。 ならば、Basic認証だけで全APIを叩くようにすれば実装が楽である。
しかし、セキュリティ的に危険。Basic認証はパスワードを使うが、通信傍受などで盗まれたらアカウントハックされる。TwoFactor認証で強化すると、30秒ごとに変わるOTPの入力が必須となり非常に実行しづらくなる。自動化もできない。
APIを叩くならToken認証
アカウントにTwoFactor認証を設定したとしても、Token認証ならOTPを必要とせずにAPIを叩けるはず。Tokenに最小限のScopeだけを指定しておけばTokenを盗まれたときの被害を最小限に抑えられる。また、盗まれてもTokenを削除すればいいだけ。再作成も簡単。アカウントハックされるより被害が少なくて済む。よって、APIを叩くときはできるだけTokenで実行したい。
Basic認証でしか使えないAPIがある
ただ、Token生成APIを叩くときはBasic認証でしか使えない。Tokenだけで全APIを実行できるわけではないため、使い分ける必要がある。