{"meta":{"title":"OAuth アプリの承認","intro":"他のユーザーが OAuth app を承認できるようにすることができます。","product":"アプリ","breadcrumbs":[{"href":"/ja/apps","title":"アプリ"},{"href":"/ja/apps/oauth-apps","title":"OAuth アプリ"},{"href":"/ja/apps/oauth-apps/building-oauth-apps","title":"OOAuth アプリの構築"},{"href":"/ja/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps","title":"OAuth アプリの承認"}],"documentType":"article"},"body":"# OAuth アプリの承認\n\n他のユーザーが OAuth app を承認できるようにすることができます。\n\n> \\[!NOTE]\n> OAuth app ではなく GitHub App を構築することを検討してください。\n>\n> OAuth apps と GitHub Apps はどちらも OAuth 2.0 を使います。\n>\n> GitHub Apps は、OAuth app と同様に、ユーザーに代わって動作することも、それ自体で動作することもできます。これはユーザー入力を必要としない自動化に役立ちます。 また、GitHub Apps ではきめ細かいアクセス許可が使われるため、アプリでアクセスできるリポジトリをより細かく制御でき、有効期間の短いトークンが使われます。 詳細については、「[GitHub アプリと OAuth アプリの違い](/ja/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps)」および「[GitHub アプリの作成について](/ja/apps/creating-github-apps/setting-up-a-github-app/about-creating-github-apps)」を参照してください。\n\nGitHub の OAuth の実装では、標準の[認可コード付与タイプ](https://tools.ietf.org/html/rfc6749#section-4.1)と、Web ブラウザーにアクセスできないアプリのための OAuth 2.0 [Device Authorization Grant](https://tools.ietf.org/html/rfc8628) がサポートされています。\n\nアプリケーションをテストする場合のように、標準的な方法でのアプリケーションの認可をスキップする場合は、[非 Web アプリケーション フロー](#non-web-application-flow)を利用できます。\n\nOAuth appを承認するには、ご自分のアプリに最適な承認フローを検討してください。\n\n* [Web アプリケーション フロー](#web-application-flow): ブラウザーで実行される標準的な OAuth apps のユーザーを承認するために使われます。 ([暗黙的な許可の種類](https://tools.ietf.org/html/rfc6749#section-4.2)はサポートされていません。)\n* [デバイスフロー](#device-flow): CLI ツールなど、ヘッドレス アプリケーションに使われます。\n\nこれらのステップを実行してください：\n\n## Web アプリケーションフロー\n\n> \\[!NOTE]\n> GitHub アプリをビルドする場合でも、OAuth Web アプリケーション フローを使用できますが、セットアップにはいくつかの重要な違いがあります。 詳細については、「[ユーザーに代わってGitHub アプリで認証する](/ja/apps/creating-github-apps/authenticating-with-a-github-app/identifying-and-authorizing-users-for-github-apps)」を参照してください。\n\nアプリケーションのユーザの認可のためのWebアプリケーションフローは以下のとおりです。\n\n1. ユーザーは、GitHub ID を要求するようにリダイレクトされます\n2. ユーザーは、GitHubによってサイトにリダイレクトされます\n3. アプリケーションはユーザのアクセストークンと共にAPIにアクセスします\n\n### 1. ユーザーのGitHub ID を要求する\n\n```\nGET https://github.com/login/oauth/authorize\n```\n\nこのエンドポイントは、次の入力パラメーターを受け取ります。\n\n| Query parameter (クエリ パラメーター) | タイプ      | 必須   | 説明                                                                                    |\n| ---------------------------- | -------- | ---- | ------------------------------------------------------------------------------------- |\n| `client_id`                  | `string` | 必須   | ユーザーが[登録](https://github.com/settings/applications/new)されたときに GitHub から受け取るクライアント ID。 |\n| `redirect_uri`               | `string` | 強く推奨 | 認可の後にユーザが送られるアプリケーション中のURL。                                                           |\n\n```\n          [リダイレクト URL](#redirect-urls) に関する詳細については、下を参照してください。 |\n```\n\n\\| `login` | `string` | 省略可能| サインインとアプリケーションの認可に使われるアカウントを指示します。 |\n\\| `scope`|`string` |コンテキスト依存|\n[スコープ](/ja/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps)のスペース区切りリスト。\n`scope` が提供されていない場合、アプリケーションに対していかなるスコープも認可していないユーザーには、既定で空のリストが使用されます。 アプリケーションに対して認可したスコープがあるユーザに対しては、スコープのリストを含むOAuthの認可ページは示されません。 その代わりに、フローのこのステップはユーザがアプリケーションに認可したスコープ群で自動的に完了します。 たとえば、ユーザーが既に Web フローを 2 回実行しており、1 つのトークンで `user` スコープを、もう 1 つのトークンで `repo` スコープを認可している場合、3 番目の Web フローで `scope` が渡されなければ、`user` および `repo` スコープを持つトークンが返されます。 |\n\\| `state` | `string` |強く推奨| データ再利用可能アプリケーションの状態記述 %} |\n\\|   |\n\\| `code_challenge` | `string` | 強く推奨 | PKCE (Proof Key for Code Exchange) を使って認証フローをセキュリティで保護するために使用されます。\n`code_challenge_method` が含まれている場合は必須です。 クライアントによって生成されたランダム文字列の 43 文字の SHA-256 ハッシュにする必要があります。 このセキュリティ拡張機能の詳細については、[PKCE の RFC](https://datatracker.ietf.org/doc/html/rfc7636) を参照してください。\n\\| `code_challenge_method` | `string` | 強く推奨 | PKCE (Proof Key for Code Exchange) を使って認証フローをセキュリティで保護するために使用されます。\n`code_challenge` が含まれている場合は必須です。\n`S256` にする必要があります。`plain` コード チャレンジ メソッドはサポートされていません。\n\\|   |\n\\| `allow_signup`|`string` | 省略可能 | 認証されていないユーザーに、OAuth フロー中にGitHubにサインアップするオプションが提供されるかどうか。 既定値は、`true` です。 ポリシーでサインアップが禁止されている場合は、`false` を使用します。 |\n\\| `prompt` | `string` | 省略可能 |\n`select_account` に設定されている場合、アカウント ピッカーを強制的に表示します。 アカウント ピッカーは、アプリケーションに HTTP 以外のリダイレクト URI がある場合、またはユーザーにサインイン済みのアカウントが複数ある場合にも表示されます。 |\n\nCORS プリフライトリクエスト (OPTIONS) は現時点ではサポートされていません。\n\n### 2. ユーザーは、GitHubによってサイトにリダイレクトされます\n\nユーザーが要求を受け入れると、GitHub は、一時的な `code` を code パラメーターに設定し、前のステップで指定した状態を `state` パラメーターに設定して、元のサイトにリダイレクトします。 一時コードは10分後に期限切れになります。 状態が一致しない場合は、リクエストがサードパーティによって作成されたものであるため、プロセスを中止する必要があります。\n\nこの `code` をアクセス トークンと交換します。\n\n```\nPOST https://github.com/login/oauth/access_token\n```\n\nこのエンドポイントは、次の入力パラメーターを受け取ります。\n\n| パラメーター名         | タイプ      | 必須   | 説明                                                                                                                                                                                                                                          |\n| --------------- | -------- | ---- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `client_id`     | `string` | 必須   | GitHub から受け取った OAuth app に対するクライアント ID。                                                                                                                                                                                                     |\n| `client_secret` | `string` | 必須   | GitHub から受け取った OAuth app に対するクライアント シークレット。                                                                                                                                                                                                 |\n| `code`          | `string` | 必須   | 手順 1 に対する応答として受け取ったコード。                                                                                                                                                                                                                     |\n| `redirect_uri`  | `string` | 強く推奨 | 認可の後にユーザが送られるアプリケーション中のURL。 これを使用して、`code` が発行されたときに最初に指定された URI と照合して、サービスに対する攻撃を防ぐことができます。                                                                                                                                                |\n|                 |          |      |                                                                                                                                                                                                                                             |\n| `code_verifier` | `string` | 強く推奨 | PKCE (Proof Key for Code Exchange) を使って認証フローをセキュリティで保護するために使用されます。 ユーザー認可中に `code_challenge` が送信された場合に必要です。 認可要求内の `code_challenge` を生成するために使った元の値にする必要があります。 アプリケーションのアーキテクチャに応じて、`state` パラメーターと共に Cookie に格納するか、認証中にセッション変数に格納することができます。 |\n|                 |          |      |                                                                                                                                                                                                                                             |\n\nデフォルトでは、レスポンスは以下の形式になります。\n\n```shell\naccess_token=gho_16C7e42F292c6912E7710c838347Ae178B4a&scope=repo%2Cgist&token_type=bearer\n```\n\n`Accept` ヘッダーに形式を指定した場合は、別の形式で応答を受け取ることもできます。 たとえば、`Accept: application/json` または `Accept: application/xml` です。\n\n```json\nAccept: application/json\n{\n  \"access_token\":\"gho_16C7e42F292c6912E7710c838347Ae178B4a\",\n  \"scope\":\"repo,gist\",\n  \"token_type\":\"bearer\"\n}\n```\n\n```xml\nAccept: application/xml\n<OAuth>\n  <token_type>bearer</token_type>\n  <scope>repo,gist</scope>\n  <access_token>gho_16C7e42F292c6912E7710c838347Ae178B4a</access_token>\n</OAuth>\n```\n\n### 3. アクセス トークンを使って API にアクセスする\n\nこのアクセストークンを使えば、ユーザの代わりにAPIへのリクエストを発行できます。\n\n```\nAuthorization: Bearer OAUTH-TOKEN\nGET https://api.github.com/user\n```\n\nたとえば、curlでは以下のようにAuthorizationヘッダを設定できます。\n\n```shell\ncurl -H \"Authorization: Bearer OAUTH-TOKEN\" https://api.github.com/user\n```\n\nアクセス トークンを受信するたびに、トークンを使用してユーザー ID を再検証する必要があります。 アプリを承認するために送信するときにユーザーはサインインしているアカウントを変更できます。サインインするたびにユーザー ID を検証しないと、ユーザー データが混在するリスクがあります。\n\n## デバイスフロー\n\nデバイスフローを使えば、CLIツールや[Git資格情報マネージャー](https://github.com/git-ecosystem/git-credential-manager)などのヘッドレスアプリケーションのユーザを認可できます。\n\nデバイス フローを使用してユーザーを認可および特定するには、まずアプリケーションの設定でデバイス フローを有効にする必要があります。 アプリでデバイス フローを有効にする方法については、GitHub Appsは「[GitHub アプリの登録の変更](/ja/apps/maintaining-github-apps/modifying-a-github-app)」、OAuth appsは「[OAuth アプリの変更](/ja/apps/oauth-apps/maintaining-oauth-apps/modifying-an-oauth-app)」を参照してください。\n\n### デバイスフローの概要\n\n1. アプリケーションはデバイスとユーザの検証コードをリクエストし、ユーザがユーザ検証コードを入力する認可URLを取得します。\n2. アプリケーションは [`https://github.com/login/device`](https://github.com/login/device)でユーザ検証コードを入力するようユーザに求めます。\n3. アプリケーションはユーザ認証のステータスをポーリングします。 ユーザがデバイスを認可すると、アプリケーションは新しいアクセストークンと共にAPIコールを発行できるようになります。\n\n### 手順 1: アプリがデバイスとユーザーの確認コードをGitHubに要求する\n\n```\nPOST https://github.com/login/device/code\n```\n\nアプリケーションは、次のステップでユーザに認可を求めるために使うユーザ検証コードと検証URLをリクエストしなければなりません。 このリクエストには、アプリケーションがアクセストークンの受け取りとユーザの認可のステータスチェックに使わなければならないデバイス検証コードも返されます。\n\nこのエンドポイントは、次の入力パラメーターを受け取ります。\n\n| パラメーター名     | タイプ      | 説明 |\n| ----------- | -------- | -- |\n| `client_id` | `string` |    |\n\n```\n          **必須。** GitHub から受け取ったアプリに対するクライアント ID。\n```\n\n`scope` | `string` | アプリがアクセスを要求しているスコープのスペース区切りのリスト。 詳しくは、「[OAuth アプリのスコープ](/ja/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps)」をご覧ください。\n\nデフォルトでは、レスポンスは以下の形式になります。\n\n```shell\ndevice_code=3584d83530557fdd1f46af8289938c8ef79f9dc5&expires_in=900&interval=5&user_code=WDJB-MJHT&verification_uri=https%3A%2F%2Fgithub.com%2Flogin%2Fdevice\n```\n\n| パラメーター名            | タイプ       | 説明                                                                                                            |\n| ------------------ | --------- | ------------------------------------------------------------------------------------------------------------- |\n| `device_code`      | `string`  | デバイス検証コードは40文字で、デバイスの検証に使われます。                                                                                |\n| `user_code`        | `string`  | ユーザ検証コードは、ユーザがブラウザに入力できるようにデバイスに表示されます。 このコードは8文字で、途中にハイフンがあります。                                              |\n| `verification_uri` | `string`  | ユーザーが `user_code` を入力する必要がある認証ページ URL:  [`https://github.com/login/device`](https://github.com/login/device)。 |\n| `expires_in`       | `integer` |                                                                                                               |\n\n```\n          `device_code` と `user_code` の有効期限か切れるまでの秒数。 デフォルトは900秒、すなわち15分です。\n```\n\n`interval` | `integer` | デバイスの認可を完了するために新しいアクセス トークンのリクエスト (`POST https://github.com/login/oauth/access_token`) を発行する前に経過する必要がある最小秒数。 たとえばintervalが5であれば、5秒が経過するまでは新しいリクエストを発行できません。 5 秒間に複数のリクエストを発行すると、レート制限に達して `slow_down` エラーが返されます。\n\n`Accept` ヘッダーに形式を指定した場合は、別の形式で応答を受け取ることもできます。 たとえば、`Accept: application/json` または `Accept: application/xml` です。\n\n```json\nAccept: application/json\n{\n  \"device_code\": \"3584d83530557fdd1f46af8289938c8ef79f9dc5\",\n  \"user_code\": \"WDJB-MJHT\",\n  \"verification_uri\": \"https://github.com/login/device\",\n  \"expires_in\": 900,\n  \"interval\": 5\n}\n```\n\n```xml\nAccept: application/xml\n<OAuth>\n  <device_code>3584d83530557fdd1f46af8289938c8ef79f9dc5</device_code>\n  <user_code>WDJB-MJHT</user_code>\n  <verification_uri>https://github.com/login/device</verification_uri>\n  <expires_in>900</expires_in>\n  <interval>5</interval>\n</OAuth>\n```\n\n### ステップ2: ブラウザでユーザコードの入力をユーザに促す\n\nデバイスはユーザ検証コードを表示し、ユーザに対してこのコードを [`https://github.com/login/device`](https://github.com/login/device)で入力するように求めます。\n\n### 手順 3: アプリがGitHubをポーリングして、ユーザーがデバイスを承認したかどうかを確認する\n\n```\nPOST https://github.com/login/oauth/access_token\n```\n\nアプリケーションでは、デバイスおよびユーザー コードが期限切れになるか、有効なユーザー コードでアプリケーションが認可されるまで、`POST https://github.com/login/oauth/access_token` をポーリングするデバイス認可リクエストを発行します。 アプリケーションでは、レート制限エラーを避けるために、ステップ 1 で取得したポーリングの最小 `interval` を使います。 詳細については、「[デバイス フローのレート制限](#rate-limits-for-the-device-flow)」を参照してください。\n\nユーザは、15分（あるいは900秒）以内に有効なコードを入力しなければなりません。 15 分が経過すると、新たなデバイス認可コードを `POST https://github.com/login/device/code` でリクエストしなければなりません。\n\nユーザが認可されると、アプリケーションはユーザの代わりにAPIにリクエストを発行するために利用できるアクセストークンを受け取ります。\n\nこのエンドポイントは、次の入力パラメーターを受け取ります。\n\n| パラメーター名     | タイプ      | 説明 |\n| ----------- | -------- | -- |\n| `client_id` | `string` |    |\n\n```\n          **必須。** GitHub から受け取った OAuth app に対するクライアント ID。\n```\n\n`device_code` | `string` |\n**必須。**\n`device_code` 要求から開発者が受け取った `POST https://github.com/login/device/code`。\n`grant_type` | `string` |\n**必須。** 付与タイプは `urn:ietf:params:oauth:grant-type:device_code` でなければなりません。\n\nデフォルトでは、レスポンスは以下の形式になります。\n\n```shell\naccess_token=gho_16C7e42F292c6912E7710c838347Ae178B4a&token_type=bearer&scope=repo%2Cgist\n```\n\n`Accept` ヘッダーに形式を指定した場合は、別の形式で応答を受け取ることもできます。 たとえば、`Accept: application/json` または `Accept: application/xml` です。\n\n```json\nAccept: application/json\n{\n \"access_token\": \"gho_16C7e42F292c6912E7710c838347Ae178B4a\",\n  \"token_type\": \"bearer\",\n  \"scope\": \"repo,gist\"\n}\n```\n\n```xml\nAccept: application/xml\n<OAuth>\n  <access_token>gho_16C7e42F292c6912E7710c838347Ae178B4a</access_token>\n  <token_type>bearer</token_type>\n  <scope>gist,repo</scope>\n</OAuth>\n```\n\n### デバイスフローのレート制限\n\nユーザがブラウザ上で検証コードをサブミットする場合、アプリケーションごとに1時間に50回のサブミットというレート制限があります。\n\nリクエスト間で要求される最小の時間間隔 (つまり `POST https://github.com/login/oauth/access_token`) 内で複数のアクセス トークン リクエスト (`interval`) を発行すると、レート制限に達し、`slow_down` エラー応答が返されます。\n`slow_down` エラー応答によって、最後の `interval` に 5 秒が追加されます。 詳細については、「[デバイス フローのエラー コード](#error-codes-for-the-device-flow)」を参照してください。\n\n### デバイスフローのエラーコード\n\n| エラー コード                 | 説明                                                                                                                                                                                            |\n| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `authorization_pending` | このエラーコードは、認可リクエストが保留中で、ユーザがユーザコードをまだ入力していない場合に生じます。 アプリケーションには、`POST https://github.com/login/oauth/access_token` を超えない範囲で `interval` リクエストをポーリングし続けることが期待されます。この際には、リクエスト間に最小の秒数を空けることが必要です。 |\n| `slow_down`             |                                                                                                                                                                                               |\n\n```\n          `slow_down` エラーが返された場合、最小の `interval`、あるいは `POST https://github.com/login/oauth/access_token` を使用するリクエスト間に必要な時間間隔に 5 秒が追加されます。 たとえば、開始時の間隔としてリクエスト間に最小で 5 秒が必要だった場合に、`slow_down` エラー応答が返されると、OAuth アクセス トークンを求める新しいリクエストの発行までに最短でも 10 秒待たなければならなくなります。 エラー応答には、使用する必要がある新しい `interval` 情報が含まれます。\n```\n\n\\| `expired_token` | デバイス コードの有効期限が切れた場合は、`token_expired` エラーが表示されます。 デバイスコードを求める新しいリクエストを発行しなければなりません。\n\\| `unsupported_grant_type` | OAuth トークン リクエストの `urn:ietf:params:oauth:grant-type:device_code` でポーリングする際には、付与タイプを `POST https://github.com/login/oauth/access_token` として、入力パラメーターに含めなければなりません。\n\\| `incorrect_client_credentials` | デバイスフローでは、アプリケーションのクライアントIDを渡さなければなりません。これは、アプリケーションの設定ページにあります。 デバイス フローに `client_secret` は必要ありません。\n\\| `incorrect_device_code` | 渡されたdevice\\_codeが有効ではありません。\n\\| `access_denied` | 認可プロセス中にユーザーがキャンセルをクリックした場合、`access_denied` エラーが返され、ユーザーは検証コードを再度利用することができなくなります。\n\\| `device_flow_disabled` | アプリケーションの設定で、デバイス フローが有効になっていません。 詳細については、「[デバイス フロー](#device-flow)」を参照してください。\n\n詳細については、「[OAuth 2.0 Device Authorization Grant](https://tools.ietf.org/html/rfc8628#section-3.5)」(OAuth 2.0 デバイス認可の付与) を参照してください。\n\n## 非Webアプリケーションフロー\n\nテストのような限定的な状況では、非Web認証が利用できます。 必要な場合は、[personal access token の設定ページ](/ja/rest/overview/authenticating-to-the-rest-api#using-basic-authentication)を使い、[基本認証](/ja/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)を使って personal access token を作成できます。 この手法を使えば、ユーザはいつでもアクセスを取り消せます。\n\n## リダイレクト URI\n\n```\n          `redirect_uri` パラメーターは省略可能です。 除外した場合、GitHubはOAuth app 設定で構成されたコールバック URL にユーザーをリダイレクトします。 指定する場合、リダイレクト URL のホスト (サブドメインを除く) とポートは、コールバック URL と完全に一致している必要があります。 リダイレクト URL のパスは、コールバック URL のサブディレクトリを参照していなければなりません。\n\nCALLBACK: http://example.com/path\n\nGOOD: http://example.com/path\nGOOD: http://example.com/path/subdir/other\nGOOD: http://oauth.example.com/path\nGOOD: http://oauth.example.com/path/subdir/other\nBAD:  http://example.com/bar\nBAD:  http://example.com/\nBAD:  http://example.com:8080/path\nBAD:  http://oauth.example.com:8080/path\nBAD:  http://example.org\n```\n\n### ループバック リダイレクト URL\n\nオプション`redirect_uri`パラメーターは、デスクトップ コンピューターで実行されているネイティブ アプリケーションに便利なLoopback URL にも使用できます。 アプリケーションでループバック URL とポートを指定した場合、アプリケーションを認可した後、ユーザーは指定した URL とポートにリダイレクトされます。\n`redirect_uri` は、アプリのコールバック URL で指定されたポートと一致している必要はありません。\n\n```\n          `http://127.0.0.1/path`コールバック URL については、アプリケーションがポート`redirect_uri`でリッスンしている場合にこの`1234`を使用できます。\n```\n\n```http\nhttp://127.0.0.1:1234/path\n```\n\nOAuth の RFC では、[`localhost` の使用は推奨されておらず](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3)、代わりにループバック リテラル `127.0.0.1` または IPv6 `::1` を使うことが推奨されています。\n\n## OAuth apps の複数のトークンを作成する\n\nユーザ／アプリケーション／スコープの組み合わせに対して複数のトークンを作成し、特定のユースケースに対応できます。\n\nこれは、OAuth app がサインインにGitHubを使用する 1 つのワークフローをサポートしており、基本的なユーザー情報のみが必要な場合に便利です。 別のワークフローはユーザのプライベートリポジトリへのアクセスを必要としていてもかまいません。 複数のトークンを使うと、OAuth appはそれぞれのユースケースに対して Web フローを実行でき、必要なスコープだけをリクエストします。 ユーザーがサインインにアプリケーションだけを使う場合は、OAuth appにプライベート リポジトリへのアクセスを付与する必要はありません。\n\nユーザー/アプリケーション/スコープの組み合わせごとに、1 時間あたり作成されるトークン数には 10 という上限があります。 アプリケーションで同じユーザーと同じスコープに対して 10 個を超えるトークンが作成された場合、同じユーザー/アプリケーション/スコープの組み合わせを持つ最も古いトークンが取り消されます。 ただし、時間単位のレート制限に達しても、最も古いトークンは取り消されません。 代わりに、ブラウザー内で再承認プロンプトがトリガーされ、ユーザーはアプリに付与しているアクセス許可を再確認するよう求められます。 このプロンプトは、アプリが 1 時間以内にユーザーに 10 個のトークンを要求する理由がほとんどないため、アプリが陥っている可能性のある無限ループを中断させることを目的としています。\n\n> \\[!WARNING]\n> OAuth app からすべてのアクセス許可を取り消すと、ユーザーの代わりにアプリケーションで生成されたすべての SSH キー ([配置キー](/ja/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys)を含む) が削除されます。\n\n## ユーザにアクセスをレビューしてもらう\n\nOAuth appへの承認情報へリンクし、ユーザーがアプリケーションの承認を確認したり、取り消したりすることができます。\n\nこのリンクを構築するには、アプリケーションの登録時に GitHub から受け取った OAuth app の `client_id` が必要です。\n\n```http\nhttps://github.com/settings/connections/applications/:client_id\n```\n\n> \\[!TIP]\n> OAuth appでアクセスできるユーザーのリソースの詳細については、「[ユーザのリソースを調べる](/ja/rest/guides/discovering-resources-for-a-user)」を参照してください。\n\n## トラブルシューティング\n\n* [認可リクエストエラーのトラブルシューティング](/ja/apps/oauth-apps/maintaining-oauth-apps/troubleshooting-authorization-request-errors)\n* [OAuth アプリ アクセス トークンのリクエスト エラーのトラブルシューティング](/ja/apps/oauth-apps/maintaining-oauth-apps/troubleshooting-oauth-app-access-token-request-errors)\n* [デバイス フロー エラー](#error-codes-for-the-device-flow)\n* [トークンの有効期限と取り消し](/ja/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation)\n\n## 参考資料\n\n* [GitHubへの認証について](/ja/authentication/keeping-your-account-and-data-secure/about-authentication-to-github)"}