21.3. アプリケーションの機能
いくつかの OAuth 2 ユーティリティーエンドポイントは、認可、トークンの更新、取り消しに使用されます。/api/o/ エンドポイントはブラウザーで使用するためのものではなく、HTTP GET をサポートしません。ここで規定するエンドポイントは OAuth 2 の RFC 仕様に厳密に準拠しているため、詳細なリファレンスとして当該 RFC を使用してください。
以下は、Automation Controller におけるこれらのエンドポイントの一般的な使用例です。特に、さまざまな付与タイプを使用してアプリケーションを作成する場合の例を示します。
21.3.1. authorization code 付与タイプを使用したアプリケーション
アクセストークンを外部アプリケーションまたはサービスに直接発行する必要がある場合は、アプリケーションの authorization code 付与タイプを使用する必要があります。
アプリケーション使用時のアクセストークンの取得には authorization code タイプのみ使用できます。外部 Web アプリケーションを Automation Controller と統合する場合、Web アプリケーションは、Web アプリケーションのユーザーに代わって OAuth2 トークンを作成する必要がある場合があります。次の理由で、Automation Controller で authorization code 付与タイプを使用してアプリケーションを作成することが推奨されます。
- 外部アプリケーションが、ユーザーの認証情報を使用してユーザーの Automation Controller からトークンを取得できるため。
- 特定のアプリケーション用に発行されたトークンが区画化されていることで、それらのトークンを簡単に管理できるため。たとえば、システム内の すべて のトークンを取り消すことなく、アプリケーションに関連付けられたすべてのトークンを取り消すことができます。
例
authorization-code 付与タイプを使用して AuthCodeApp という名前のアプリケーションを作成するには、/api/v2/applications/ エンドポイントに対して POST を実行します。
{
"name": "AuthCodeApp",
"user": 1,
"client_type": "confidential",
"redirect_uris": "http://<controller>/api/v2",
"authorization_grant_type": "authorization-code",
"skip_authorization": false
}
.. _`Django-oauth-toolkit simple test application`: http://django-oauth-toolkit.herokuapp.com/consumer/
response_type、client_id、redirect_uris、および scope を使用して、クライアントアプリケーションから authorize エンドポイントに GET 要求を送信する場合、以下のワークフローが発生します。
-
Automation Controller は、アプリケーションで指定された
redirect_uriに対して、認可コードとステータスで応答します。 -
次に、クライアントアプリケーションは、
code、client_id、client_secret、grant_type、およびredirect_uriを使用して、Automation Controller のapi/o/token/エンドポイントに POST 要求を送信します。 -
Automation Controller は、
access_token、token_type、refresh_token、およびexpires_inで応答します。
このワークフローの詳細およびテストについては、Django OAuth Toolkit の Test Your Authorization Server を参照してください。
System settings ページで、認可コードが有効な期間を秒単位で指定できます。
この期間の経過後にアクセストークンを要求すると失敗します。
期間のデフォルトは、RFC6749 の推奨に基づいて 600 秒 (10 分) です。
認可コード付与タイプを使用してアプリケーション統合をセットアップする最良の方法は、クロスサイト要求の発信元を許可リストに登録することです。より一般的には、アクセストークンを提供する対象である、Automation Controller と統合するサービスまたはアプリケーションを許可リストに登録する必要があります。
これを行うには、管理者に /etc/tower/conf.d/custom.py のローカル Automation Controller 設定にこの許可リストを追加してもらいます。
CORS_ORIGIN_ALLOW_ALL = True
CORS_ALLOWED_ORIGIN_REGEXES = [
r"http://django-oauth-toolkit.herokuapp.com*",
r"http://www.example.com*"
]
ここで、http://django-oauth-toolkit.herokuapp.com と http://www.example.com は、Automation Controller にアクセスするためにトークンが必要なアプリケーションです。
21.3.2. password 付与タイプを使用したアプリケーション
password 付与タイプまたは Resource owner password-based 付与タイプは、Web アプリケーションへのネイティブアクセスを持つユーザーに最適であり、クライアントがリソースオーナーの場合に使用する必要があります。以下では、付与タイプが password である "Default Application" というアプリケーションを前提としています。
{
"id": 6,
"type": "application",
...
"name": "Default Application",
"user": 1,
"client_id": "gwSPoasWSdNkMDtBN3Hu2WYQpPWCO9SwUEsKK22l",
"client_secret": "fI6ZpfocHYBGfm1tP92r0yIgCyfRdDQt0Tos9L8a4fNsJjQQMwp9569eIaUBsaVDgt2eiwOGe0bg5m5vCSstClZmtdy359RVx2rQK5YlIWyPlrolpt2LEpVeKXWaiybo",
"client_type": "confidential",
"redirect_uris": "",
"authorization_grant_type": "password",
"skip_authorization": false
}
password 付与タイプではログインは必要ないため、curl を使用して /api/v2/tokens/ エンドポイント経由でパーソナルアクセストークンを取得できます。
curl -k --user <user>:<password> -H "Content-type: application/json" \
-X POST \
--data '{
"description": "Token for Nagios Monitoring app",
"application": 1,
"scope": "write"
}' \
https://<controller>/api/v2/tokens/
特別な OAuth 2 エンドポイントは、x-www-form-urlencoded という Content-type の使用のみをサポートします。したがって、api/o/* エンドポイントで application/json を受け入れるものはありません。
成功すると、アクセストークン、リフレッシュトークン、その他の情報を含む応答が JSON 形式で表示されます。
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Tue, 05 Dec 2017 16:48:09 GMT
Content-Type: application/json
Content-Length: 163
Connection: keep-alive
Content-Language: en
Vary: Accept-Language, Cookie
Pragma: no-cache
Cache-Control: no-store
Strict-Transport-Security: max-age=15768000
{"access_token": "9epHOqHhnXUcgYK8QanOmUQPSgX92g", "token_type": "Bearer", "expires_in": 315360000000, "refresh_token": "jMRX6QvzOTf046KHee3TU5mT3nyXsz", "scope": "read"}