その他の認証方式

API は複数の認証方式を提供していますが、本番アプリケーションには OAuth を使用することを強くお勧めします。 他の方式は、スクリプトまたはテスト（完全な OAuth では過剰になる場合）に使用するために提供されています。 認証に GitHub を利用するサードパーティのアプリケーションでは、GitHub 認証情報を要求または収集してはなりません。 代わりに、OAuth web フローを使用してください。

Basic 認証

API は、RFC2617 で定義されている Basic 認証をサポートしていますが、若干の違いがあります。 主な違いは、RFC では、認証されていないリクエストに 401 Unauthorized レスポンスで応える必要がある点です。 これにより、多くの場所でユーザデータの存在が明らかになります。 代わりに、GitHub API は 404 Not Found で応答します。 これにより、401 Unauthorized レスポンスを想定する HTTP ライブラリで問題が発生する可能性があります。 これは Authorization ヘッダを手動で作成することで解決できます。

OAuth と個人アクセストークンを使用する

GitHub API への認証には OAuth トークンを使用することをお勧めします。 OAuth トークンには個人アクセストークンが含まれており、ユーザはいつでもアクセスを取り消すことができます。

$ curl -u username:token https://api.github.com/user

このアプローチは、ツールが Basic 認証のみをサポートしているが、OAuth アクセストークンのセキュリティ機能を利用したい場合に役立ちます。

ユーザ名とパスワードを使用する

SAML SSO を認証する

認証にSAML SSOを強制しているOrganizationにアクセスするためAPIを使用している場合は、個人アクセストークン (PAT) を作成し、Organizationに対してそのトークンを認証する必要があります。 X-GitHub-SSO で指定された URL にアクセスして、Organization のトークンを承認します。

$ curl -v -H "Authorization: token TOKEN" https://api.github.com/repos/octodocs-test/test

> X-GitHub-SSO: required; url=https://github.com/orgs/octodocs-test/sso?authorization_request=AZSCKtL4U8yX1H3sCQIVnVgmjmon5fWxks5YrqhJgah0b2tlbl9pZM4EuMz4
{
  "message": "Resource protected by organization SAML enforcement. You must grant your personal token access to this organization.",
  "documentation_url": "https://docs.github.com"
}

複数の Organization からのデータをリクエストする場合（たとえば、ユーザが作成した Issue のリストをリクエストする場合）、X-GitHub-SSO ヘッダは、個人アクセストークンを承認する必要がある Organization を示します。

$ curl -v -H "Authorization: token TOKEN" https://api.github.com/user/issues

> X-GitHub-SSO: partial-results; organizations=21955855,20582480

organizations の値は、個人アクセストークンの承認が必要な Organization の Organization IDのカンマ区切りのリストです。

2 要素認証を使用する

2 要素認証を有効にしている場合、REST API のほとんどのエンドポイントの Basic 認証では、個人アクセストークン を使用する必要があります。

using GitHub 開発者設定を使用して新しい個人アクセストークンを生成することができます。 詳しい情報については、「コマンドラインの個人アクセストークンを作成する」を参照してください。 これらのトークンを使用し、GitHub API で OAuth トークンを使用して認証します。