Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第21章 トークンベースの認証

OAuth 2 は、トークンベースの認証に使用されます。OAuth トークンとアプリケーション、つまりトークンの生成に使用する API クライアントのサーバー側の表現を管理できます。OAuth トークンを HTTP 認証ヘッダーの一部として含めることにより、自身を認証し、基本の RBAC パーミッションに加えて制限的なパーミッションのレベルを調整できます。

OAuth2 仕様の詳細は、The OAuth 2.0 Authorization Framework を参照してください。

manage ユーティリティーを使用してトークンを作成する方法の詳細は、トークンおよびセッション管理 を参照してください。

21.1. OAuth 2 アプリケーションおよびトークンの管理
リンクのコピー

アプリケーションとトークンは、/api/<version>/applications および /api/<version>/tokens でトップレベルのリソースとして管理できます。これらのリソースには、/api/<version>/users/N/<resource> でユーザーごとにアクセスすることもできます。アプリケーションを作成するには、api/<version>/applications または /api/<version>/users/N/applications に POST を実行します。

各 OAuth 2 アプリケーションは、サーバー側で特定の API クライアントを表現します。API クライアントがアプリケーショントークンを介して API を使用するには、まずアプリケーションを用意し、アクセストークンを発行する必要があります。個々のアプリケーションには、/api/<version>/applications/<pk>/ にあるプライマリーキーを使用してアクセスできます。

以下は、一般的なアプリケーションです。 

{
    "id": 1,
    "type": "o_auth2_application",
    "url": "/api/v2/applications/2/",
    "related": {
        "tokens": "/api/v2/applications/2/tokens/"
    },
    "summary_fields": {
        "organization": {
            "id": 1,
            "name": "Default",
            "description": ""
        },
        "user_capabilities": {
            "edit": true,
            "delete": true
        },
        "tokens": {
            "count": 0,
            "results": []
        }
    },
    "created": "2018-07-02T21:16:45.824400Z",
    "modified": "2018-07-02T21:16:45.824514Z",
    "name": "My Application",
    "description": "",
    "client_id": "Ecmc6RjjhKUOWJzDYEP8TZ35P3dvsKt0AKdIjgHV",
    "client_secret": "7Ft7ym8MpE54yWGUNvxxg6KqGwPFsyhYn9QQfYHlgBxai74Qp1GE4zsvJduOfSFkTfWFnPzYpxqcRsy1KacD0HH0vOAQUDJDCidByMiUIH4YQKtGFM1zE1dACYbpN44E",
    "client_type": "confidential",
    "redirect_uris": "",
    "authorization_grant_type": "password",
    "skip_authorization": false,
    "organization": 1
}
Copy to Clipboard Toggle word wrap

ここで、name は、人間が判読できるアプリケーションの識別子です。client_id や redirect_uris などの残りのフィールドは、主に OAuth2 認可に使用されます。この点は、パーソナルアクセストークン (PAT) 向けの OAuth2 トークンシステムの使用 で説明されています。

client_id および client_secret フィールドの値は作成時に生成されるアプリケーション識別子で、編集できません。一方で、organization および authorization_grant_type は作成時に必要で、その後に編集不可になります。

21.1.1. アプリケーションのアクセスルール
リンクのコピー

アプリケーションのアクセスルールは以下のとおりです。

  • システム管理者は、システム内のすべてのアプリケーションを表示し、操作できます。
  • 組織の管理者は、組織メンバーに属するすべてのアプリケーションを表示し、操作できます。
  • 他のユーザーは、自身のアプリケーションの表示、更新、削除が可能ですが、新規アプリケーションは作成できません。

一方、トークンは、受信要求を認証し、基盤のユーザーのパーミッションをマスクするために使用するリソースです。

トークンを作成するには 2 つの方法があります。

  • /api/v2/tokens/ エンドポイントに POST 要求を送信します。application フィールドと scope フィールドは、関連アプリケーションを参照してトークンスコープを指定するように設定します。
  • scope フィールドを使用して /api/v2/applications/<pk>/tokens/ エンドポイントに POST 要求を送信します (親アプリケーションは自動的にリンクされます)。

個々のトークンは、に/api/<version>/tokens/<pk>/ にあるプライマリーキーを使用してアクセスできます。

以下は一般的なトークンの例です。 

{
    "id": 4,
    "type": "o_auth2_access_token",
    "url": "/api/v2/tokens/4/",
    "related": {
        "user": "/api/v2/users/1/",
        "application": "/api/v2/applications/1/",
        "activity_stream": "/api/v2/tokens/4/activity_stream/"
},
    "summary_fields": {
        "application": {
            "id": 1,
            "name": "Default application for root",
            "client_id": "mcU5J5uGQcEQMgAZyr5JUnM3BqBJpgbgL9fLOVch"
        },
        "user": {
            "id": 1,
            "username": "root",
            "first_name": "",
            "last_name": ""
        }
    },
    "created": "2018-02-23T14:39:32.618932Z",
    "modified": "2018-02-23T14:39:32.643626Z",
    "description": "App Token Test",
    "user": 1,
    "token": "*************",
    "refresh_token": "*************",
    "application": 1,
    "expires": "2018-02-24T00:39:32.618279Z",
    "scope": "read"
},
Copy to Clipboard Toggle word wrap

OAuth 2 トークンの場合、完全に編集可能なフィールドは、scope と description のみです。application フィールドは更新時に編集できず、他のフィールドはすべて編集できません。これらは作成時に自動で次のように入力されます。

  • user フィールドは、トークンの作成対象のユーザーに対応します。この場合、トークンを作成するユーザーでもあります。
  • expires は、Automation Controller の設定 OAUTH2_PROVIDER に従って生成されます。
  • token および refresh_token は、クラッシュなしの乱数文字列として自動生成されます。

アプリケーショントークンとパーソナルアクセストークンは両方とも /api/v2/tokens/ エンドポイントに表示されます。パーソナルアクセストークンの application フィールドは常に null です。これにより、2 種類のトークンを区別できます。

21.1.2. トークンのアクセスルール
リンクのコピー

トークンのアクセスルールは以下のとおりです。

  • ユーザーは、関連のアプリケーションを表示できる場合にはトークンを作成でき、自身の個人トークンも作成可能です。
  • システム管理者は、システム内のすべてのトークンを表示し、操作できます。
  • 組織の管理者は、組織メンバーに属するすべてのトークンを表示し、操作できます。
  • システム監査者は、すべてのトークンおよびアプリケーションの表示が可能です。
  • 他の通常ユーザーは、自身のトークンのみ表示し、操作できます。
注記

ユーザーは、作成時にのみトークンの表示またはトークンの値の更新が可能です。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る