第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 }
ここで、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" },
OAuth 2 トークンの場合、完全に編集可能なフィールドは、scope
と description
のみです。application
フィールドは更新時に編集できず、他のフィールドはすべて編集できません。これらは作成時に自動で次のように入力されます。
-
user
フィールドは、トークンの作成対象のユーザーに対応します。この場合、トークンを作成するユーザーでもあります。 -
expires
は、Automation Controller の設定OAUTH2_PROVIDER
に従って生成されます。 -
token
およびrefresh_token
は、クラッシュなしの乱数文字列として自動生成されます。
アプリケーショントークンとパーソナルアクセストークンは両方とも /api/v2/tokens/
エンドポイントに表示されます。パーソナルアクセストークンの application
フィールドは常に null です。これにより、2 種類のトークンを区別できます。
21.1.2. トークンのアクセスルール
トークンのアクセスルールは以下のとおりです。
- ユーザーは、関連のアプリケーションを表示できる場合にはトークンを作成でき、自身の個人トークンも作成可能です。
- システム管理者は、システム内のすべてのトークンを表示し、操作できます。
- 組織の管理者は、組織メンバーに属するすべてのトークンを表示し、操作できます。
- システム監査者は、すべてのトークンおよびアプリケーションの表示が可能です。
- 他の通常ユーザーは、自身のトークンのみ表示し、操作できます。
ユーザーは、作成時にのみトークンの表示またはトークンの値の更新が可能です。