CLion 2026.2 Help

OAuth 2.0 認証

HTTP クライアントは OAuth 2.0 認証をサポートします。 アクセストークンを取得し、OAuth 2.0 で保護されたリソースへのリクエストを認証できます。 ユーザー認証情報を入力できるようにするために、HTTP クライアントは組み込みの JCEF ブラウザーにログインフォームを表示します。 この非モーダルブラウザーでは、IDE での作業が妨げられることはなく、たとえば、ユーザー名とパスワードをコピーして貼り付けることができます。

一般的なフローには次のステップが含まれます:

  1. 認証設定を指定する (認可タイプやトークン URL など) (パブリック環境ファイル内の JSON 形式)。

  2. HTTP リクエストで $auth.token 変数を使って この認証構成を参照します

  3. リクエストを実行します。 認証が成功すると、保護されたリソースにアクセスできます。 受信したアクセストークンとリフレッシュトークンは、 HTTP クライアント認証ログ または サービス ツールウィンドウで確認できます。

  4. アクセストークンを手動でリフレッシュしたり、 新しいトークンを要求して認証手順を再初期化したりすることもできます。

認証構成の作成

  1. .http ファイルの 実行 リストで、認証構成を追加する環境を選択します。

  2. ツールバーで「追加アイコン 」をクリックし、「認証構成 」を選択します。

    これにより、選択した環境の "セキュリティ" にある "Auth" オブジェクト内のパブリック環境ファイルに認証構成テンプレートが追加されます。 例:

    { "dev": { "Security": { "Auth": { "auth-id": { "Type": "OAuth2", "Grant Type": "", "Client ID": "" } } } } }
  3. プレースホルダー auth-id を、 .http ファイル内でこの構成を参照するために使用する意味のある名前に置き換えます。

  4. 認証パラメーターを指定します。 必要なパラメーターは選択した "Grant Type" によって異なります。 認証パラメーターを入力する際、CLion コーディング支援を使用可能です。パラメーターの名前を入力し始めるか、 Ctrl+Space を押すと、利用可能な JSON 鍵の一覧が表示されます。

HTTP リクエストで認証構成を使用する

認証構成を作成すれば、それを使用してアクセストークンを取得し、リクエストの認証に使用できます。

  1. 認証構成の名前を {{$auth.token()}} 変数に渡します (例: {{$auth.token("my-config")}})。 この変数は、リクエスト Authorization ヘッダーまたはクエリパラメーターで使用できます。

  2. 実行 」をクリックしてリクエストを送信します。 保護されたリソースにアクセスする前に、HTTP クライアントは認可サーバーにリクエストを送信してアクセストークンを取得します。

  3. プロンプトが表示されたら、認証プロセスを完了します。 認証が正常に完了すると、HTTP クライアントは保護されたリソースにアクセスします。

{{$auth.token()}} 変数をすばやく追加するには、ライブテンプレートを使用します:HTTP メソッドのヘッダーセクションで AuthorizationToken と入力し、表示される候補のリストから利用可能な認証を選択します。

HTTP Client auth configuration

このようなリクエストを実行すると、 サービス ツールウィンドウで 認証ログの表示 ボタンが使用できるようになります。 リダイレクトページ、アクセストークン、その他の認証の詳細を表示できます。

アクセストークンを手動で取得する

HTTP リクエストで認証構成を参照すると、HTTP クライアントは、保護されたリソースにアクセスする前にアクセストークンを自動的に取得 (またはリフレッシュ) します。 保護されたリソースに実際のリクエストを送信せずにアクセストークンを取得したい場合は、アクセストークンを手動で取得できます。

  1. http-client.env.json ファイルで、認証構成名の横にある 実行 をクリックします。

  2. 認証構成に プライベート変数が含まれている場合は、表示されるポップアップでプライベート環境ファイルを選択します。

  3. プロンプトが表示されたら、認証プロセスを完了します。

認証が正常に完了すると、CLion がアクセストークンを取得します。 すでにアクセストークンを持っていて有効期限が切れている場合、CLion がアクセストークンをリフレッシュします。

新しいアクセストークンを取得する

トークンをリフレッシュするだけでなく、再認証により、つまり最初のアクセストークンを取得した際の元のフローを繰り返すことで、新しいトークンを取得できます。

  1. http-client.env.json ファイルで、認証構成名にキャレットを置きます。

  2. Alt+Enter (コンテキストアクションの表示) を押して、 認証トークンの強制取得 を選択します。

  3. 認証構成に プライベート変数が含まれている場合は、表示されるポップアップでプライベート環境ファイルを選択します。

キャレットが .http ファイル内の $auth.token 変数上にある場合、同じアクションを呼び出すことができます。 この場合、HTTP クライアントは .http ファイルと同じフォルダーにある環境ファイルを使用するため、プライベート環境ファイルを選択する必要はありません。

新しいトークンをリフレッシュまたは取得すると、アクセスおよびリフレッシュトークンとその他の認証の詳細が HTTP クライアント認証ログ ツールウィンドウ (表示 | ツールウィンドウ | HTTP クライアント認証ログ) に表示されます。

HTTP クライアント認証ログツールウィンドウ

ブラウザーの Cookie をクリア

認可サーバーは、ブラウザーの Cookie に認証データを保存する場合があります。 異なるデータを使用して認証フローをテストする場合は、組み込みの JCEF ブラウザーの Cookie をクリアする必要がある場合があります。

  1. http-client.env.json ファイルで、認証構成名にキャレットを置き、 Alt+Enter (コンテキストアクションの表示) を押します。

  2. ブラウザーの Cookie をクリア を選択します。

または、 HTTP クライアント認証ログ ツールウィンドウで Cookie をクリア をクリックして Cookie をクリアすることもできます。

アクセストークンの代わりに ID トークンを使用する

サーバーでアクセストークンの代わりに ID トークンの使用が必要な場合、HTTP クライアントを次のいずれかの方法で構成できます:

  • 認証構成では、 "Use ID Token": true パラメーターを使用します。

  • .http ファイルでは、 $auth.idToken 変数 (例: Authorization: Bearer {{$auth.idToken("auth-id-1")}}) を使用します。

カスタム認証パラメーターを使用する

HTTP クライアントには、認可サーバーが必要とするカスタムリクエストパラメーターを定義するオプションが用意されています。 これには、たとえば、OAuth 2.0 認可フレームワークを拡張する resourceaudience が含まれます。

  1. 認証構成に、 "Custom Request Parameters" オブジェクトを追加します。

  2. "Custom Request Parameters" 内に、パラメーター名と値 (文字列または配列) を入力します。

  3. パラメーターの使用を特定のリクエストに制限する場合は、値をオブジェクト(キーは 2 つ)として定義します:

    • "値" (パラメーター値)

    • "Use" — パラメーターの使用スコープ。 次の 3 つの値のいずれかになります。

      • "Use": "Everywhere" (いかなるリクエストでも)

      • "Use": "In Auth Request" (認証リクエストのみ)

      • "Use": "In Token Request" (トークンリクエストのみ)

    例:

    "auth-id-1": { "Type": "OAuth2", "Custom Request Parameters": { "audience": { "Value": "https://my-audience.com/", "Use": "In Token Request" }, "resource": [ "https://my-resource/resourceId1", "https://my-resource/resourceId2" ], "my-custom-parameter": "my-custom-value" }, }

HTTP クライアント認証ログ ツールウィンドウを使用して、リクエストで使用されるパラメーターとその値を表示します。

カスタムリクエストヘッダーを使用する

HTTP クライアントには、認可サーバーで必要となる可能性のあるカスタム要求ヘッダーを使用するオプションが用意されています。

  1. 認証構成に、 "Custom Request Headers" オブジェクトを追加します。

  2. "Custom Request Headers" 内に、ヘッダー名とその値を入力します。

    Ctrl+Space を押すと、 受諾CookieUser-Agent などの一般的なヘッダーの候補リストが表示されます。

  3. ヘッダーの使用を特定のリクエストに制限する場合は、値を 2 つのキーを持つオブジェクトとして定義します。

    • "値" (ヘッダー値)

    • "Use" — ヘッダーの使用スコープ。 次の 3 つの値のいずれかになります。

      • "Use": "Everywhere" (いかなるリクエストでも)

      • "Use": "In Auth Request" (認証リクエストのみ)

      • "Use": "In Token Request" (トークンリクエストのみ)

    例:

    "auth-id-1": { "Type": "OAuth2", "Custom Request Headers": { "Accept": { "Use": "Everywhere", "Value": "application/javascript" }, "my-custom-header": "my-custom-value" }, }

認証構成パラメーター

タイプ

認証タイプ。 可能な値:

  • "OAuth2": OAuth2 を使用してリクエストを認証します。

  • "Mock" (開発またはテスト環境の場合):認証処理をエミュレートします。OAuth2 サーバーから提供されたアクセストークンの代わりに、CLion は認証構成にあるトークンを使用します。 "トークン" をアクセストークンとして、必要に応じて "ID Token" を ID トークンとして指定します。 例:

    "my-auth-id": { "Type": "Mock", "Token": "my-token" }
認可タイプ

アクセストークンを取得するメソッドです。 可能な値: "Authorization Code""Client Credentials""Device Authorization""暗黙的" 、および "パスワード"

認可 URL

アプリケーションが認可コードを取得するためにクライアントリクエストをリダイレクトする認可 URL です。 認可コードおよび暗黙グラントタイプには "Auth URL" が必要です。

トークン URL

認証コードをアクセストークンと交換するためのプロバイダーの認証サーバーです。 認可コード、クライアント資格情報、デバイス認証、およびパスワード付与タイプには "Token URL" が必要です。

リダイレクト URL

クライアントアプリケーションの コールバック URLは、認証後にリクエストをリダイレクトする先です。 これはクライアントアプリケーション設定の URL か、認可サーバーが任意の URL を受け入れる場合は、たとえば http://localhost:12345/foo/bar のような任意の URL です。

クライアント ID

API プロバイダーに登録したクライアントの公開識別子です。 すべての 認可タイプにはこのパラメーターが必要です。

クライアントシークレット

クライアントアプリケーションが認証サーバーに対して認証するために使用する機密識別子です。 クライアント資格情報 認可タイプにはこのパラメーターが必要です。

クライアント資格情報

次のいずれかを入力してください:

  • リクエストでクライアント資格情報を指定したくない場合は、 "なし"

  • リクエスト本文でクライアント資格情報を送信する場合は、 "in body"

  • "basic" は、要求ヘッダーで基本認証要求を送信します (デフォルト値)。

デバイス認証 URL

クライアントデバイスがデバイスコードとユーザーコードを取得するためにリクエストする URL です。

デバイス認証付与タイプに適用され必須です。

完全な URI を開く

true に設定すると、ブラウザーはユーザーコードを含む検証 URI(verification_uri_complete )を開きます。 デフォルト値は false です。ブラウザーは検証 URI(ユーザーコード埋込なし)を開き、通常ユーザーが手動でコード入力するようになっています。

デバイス認証付与タイプで利用可能です。

ブラウザーの後にポーリングを開始

true に設定すると、クライアントデバイスはブラウザーが閉じられた後にのみトークンエンドポイントへアクセストークンリクエスト(ポーリング)を送る必要があります。 デフォルト値は false です。デバイスはユーザーが操作を終えるかコードが失効するまで、トークンエンドポイントを継続的にポーリングします。

デバイス認証付与タイプで利用可能です。

PKCE

コード交換のための証明キー (PKCE)(英語) を有効にします。 認可コード付与タイプに適用可能です。

デフォルトのアルゴリズム (自動生成されたコード検証の SHA-256 ハッシュ) を使用するには、 "PKCE": true と入力します。 または、 "Code Challenge Method" (プレーンまたは SHA-256) と "Code Verifier" を使用して動作をカスタマイズします。 例:

"PKCE": { "Code Challenge Method": "Plain", "Code Verifier": "YYLzIBzrXpVaH5KRx86itubKLXHNGnJBPAogEwkhveM" },
スコープ

アプリケーションがユーザーアカウントにアクセスできる範囲を制限するスコープ。 可能な値はアクセスするサービスによって異なります。

自動的に取得

デフォルトでは、HTTP クライアントはリクエストを送信する前にアクセストークンを自動的にリフレッシュまたは取得します。 リクエストを送信する前にアクセストークンを自動的にリフレッシュまたは取得したくない場合は、「"Acquire Automatically": false 」と入力します。 手動でリフレッシュまたは取得できます。

ユーザー名

認証の一部として送信されるユーザー名で、パスワード認可タイプと併用されます。

パスワード

認証の一部として送信されるユーザーパスワードで、パスワード認可タイプと併用されます。 パスワードを共有しないようにするには、値の代わりに プライベート変数を利用できます。たとえば、 "Password": "{{password}}" です。

カスタムリクエストパラメーター

カスタムリクエストパラメーターを指定

カスタムリクエストヘッダー

カスタムリクエストヘッダーを指定

2026 年 7 月 15 日