2.3.2. OAuth トークン要求


OpenShift Dedicated は、ブラウザーベースのツールや CLI ツールなど、さまざまなユーザーエージェントからのトークン要求を処理するために、OAuth クライアントを自動的に作成します。これらのクライアントは、OAuth エンドポイントと連携して、対話型のログインフローまたは WWW 認証チャレンジを通じてユーザーを認証します。

以下の OAuth クライアントは、OpenShift Dedicated API の起動時に自動的に作成されます。

Expand
OAuth クライアント使用法

openshift-browser-client

対話式ログインを処理できるユーザーエージェントで <namespace_route>/oauth/token/request でトークンを要求します。[1]

openshift-challenging-client

WWW-Authenticate チャレンジを処理できるユーザーエージェントでトークンを要求します。

  1. <namespace_route> は namespace のルートを参照します。これは、以下のコマンドを実行して確認できます。

    $ oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host

OAuth トークンのすべての要求には <namespace_route>/oauth/authorize への要求が必要になります。ほとんどの認証統合では、認証プロキシーをこのエンドポイントの前に配置するか、または OpenShift Dedicated を、サポートするアイデンティティープロバイダーに対して認証情報を検証するように設定します。<namespace_route>/oauth/authorize の要求は、CLI などの対話式ログインページを表示できないユーザーエージェントから送られる場合があります。そのため、OpenShift Dedicated は、対話式ログインフローのほかにも WWW-Authenticate チャレンジを使用した認証をサポートします。

認証プロキシーが <namespace_route>/oauth/authorize エンドポイントの前に配置される場合は、対話式ログインページを表示したり、対話式ログインフローにリダイレクトする代わりに、認証されていない、ブラウザー以外のユーザーエージェントの WWW-Authenticate チャレンジを送信します。

注記

ブラウザークライアントに対するクロスサイトリクエストフォージェリー (CSRF) 攻撃を防止するため、基本的な認証チャレンジは X-CSRF-Token ヘッダーが要求に存在する場合にのみ送信されます。基本的な WWW-Authenticate チャレンジを受信する必要があるクライアントでは、このヘッダーを空でない値に設定する必要があります。

認証プロキシーが WWW-Authenticate チャレンジをサポートできない場合、または OpenShift Dedicated が WWW-Authenticate チャレンジをサポートしていないアイデンティティープロバイダーを使用するように設定されている場合は、ブラウザーを使用して <namespace_route>/oauth/token/request からトークンを手動で取得する必要があります。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る